As agile divas coaches, we are prone to think things like: "agile is never going to work in a company [like this one] with a horrible, toxic culture. [but I will take the money and give it a shot. What the hey, it's job security.]." In fact, "company philosophy or
culture" was one of the top two "leading causes of failed Agile efforts" for the 2008, 2009, 2010, 2011, and 2012 "State of Agile"
Surveys administered by the Scrum Alliance. And I don't think the 2013 results are out yet.
One pictures the coaches of the world flouncing around in art deco silk wraps and soft curlers waving our collective hands and wailing things about "not being able to work under these conditions!" It's poison I tell you, poison!
But let's turn the question around. If we, as agile coaches, have a preference to work solely
with small groups of (kind) super-geniuses in converted warehouses
which have bean bag chairs, and everyone is playing the
dulcimer all the time, let's own that as a personal preference, but let's
not build it into a whole theory we force on others. And by the way, how many real-life companies have we coached at that turned out to be Nirvana? Were the bean bags in the break room a lead indicator for anything except germs from people who drool while they are napping? The Intelligencia coffee is free, but it isn't decaf. Nobody cleans out the refrigerator.
Let's stop asking "what my company culture can do (or not do) for agile," and ask instead, "what is the best business option here?" Nine times out of ten, the best option will be to apply agile philosophy and methods, and not just the superficial ones like "stand up meetings" and "burn down charts." Politically challenging organizations are especially good places to set up teams to self-organize into a state of extremely high productivity using our best techniques--sustainable pace, evolutionary design, refactoring, continuous delivery pipelines, real options, feature/behavior driven development, deploying from trunk, and especially information radiators even including bullhorns that go off when the build breaks.
Why, you ask? Three reasons:
1) Productivity. Most techniques under the agile umbrella can be deployed independently, one at a time, and they can provide proven results in terms of productivity, quality, total cost of ownership, speed to market, awareness of risk, controls, and so on. Embrace cafeteria agile! Automated testing. Automated build and deploy. Virtualization. Collocated kick-off workshop to align on scope. Attending to intrinsic code quality. Suss out your client's perceived pain points. Make a case for what practices you suggest to fix those things at lowest cost to them. Coach those practices for the allotted time to confirm you were right. You have created a benefit in a challenging environment. And that's a good thing.
2) Skills. Regardless of how you feel about the people at your organization when you talk about "the culture," at the end of the day, the enterprise is comprised of a group of people who have a variety of motives for the engagement. Proper agile coaching provides every participant of your engagement with something new to bring to work each day, whether here, or at their next job. Sometimes it's best to stop looking so hard at the forest and start hugging individual trees. Coach those people. You have allowed some group of people to feel more excited about their work. And that's a good thing.
3) Power. Bottom line: knowledge is power, and agile delivers knowledge frequently, at high fidelity. You have a unique product to sell here. In cynical, cutthroat cultures, the survivors who have clambered successfully to the top board and executive positions are especially hungry for information which is spin-resistant. Facts are rarer than diamonds in waterfall enterprise software development:
So stop being such a wuss. Embrace the challenge. Own the factual changes you can create. Own the techniques you can bring to the people who want to hear about them. And own your ability to bestow actual power to your clients, and the value that power brings them. In the end, this is the only way to measure your effectiveness. And seriously, wash your hands after occupying a used bean bag chair. It's flu season.
One pictures the coaches of the world flouncing around in art deco silk wraps and soft curlers waving our collective hands and wailing things about "not being able to work under these conditions!" It's poison I tell you, poison!
 |
| From the excellent http://www.theculturedoctor.com.au/blog |
Let's stop asking "what my company culture can do (or not do) for agile," and ask instead, "what is the best business option here?" Nine times out of ten, the best option will be to apply agile philosophy and methods, and not just the superficial ones like "stand up meetings" and "burn down charts." Politically challenging organizations are especially good places to set up teams to self-organize into a state of extremely high productivity using our best techniques--sustainable pace, evolutionary design, refactoring, continuous delivery pipelines, real options, feature/behavior driven development, deploying from trunk, and especially information radiators even including bullhorns that go off when the build breaks.
Why, you ask? Three reasons:
1) Productivity. Most techniques under the agile umbrella can be deployed independently, one at a time, and they can provide proven results in terms of productivity, quality, total cost of ownership, speed to market, awareness of risk, controls, and so on. Embrace cafeteria agile! Automated testing. Automated build and deploy. Virtualization. Collocated kick-off workshop to align on scope. Attending to intrinsic code quality. Suss out your client's perceived pain points. Make a case for what practices you suggest to fix those things at lowest cost to them. Coach those practices for the allotted time to confirm you were right. You have created a benefit in a challenging environment. And that's a good thing.
2) Skills. Regardless of how you feel about the people at your organization when you talk about "the culture," at the end of the day, the enterprise is comprised of a group of people who have a variety of motives for the engagement. Proper agile coaching provides every participant of your engagement with something new to bring to work each day, whether here, or at their next job. Sometimes it's best to stop looking so hard at the forest and start hugging individual trees. Coach those people. You have allowed some group of people to feel more excited about their work. And that's a good thing.
3) Power. Bottom line: knowledge is power, and agile delivers knowledge frequently, at high fidelity. You have a unique product to sell here. In cynical, cutthroat cultures, the survivors who have clambered successfully to the top board and executive positions are especially hungry for information which is spin-resistant. Facts are rarer than diamonds in waterfall enterprise software development:
- Except at release time, it's anyone's bet about what is going to happen. If you have a project which will take 12-18 months from requirements to completed software, and you launch one of these every few months, you are making a series of expensive overlapping long-term bets. You can use phrases like "earned value" all you want, but that's just a fancy way of saying "we're halfway through the requirements period, and we're looking good." How good? It depends on how fast the requirements are changing in the background, how well the desired functionality is passed from hand to hand inside the development group without losing fidelity, and how lucky the team is in terms of estimated effort compared to actual. And it depends especially on how well the stakeholders spin the tantalizing hints of information they have available. In a company with a major release 4 times per year, an executive with responsibility for waterfall projects knows something tangible 4 days out of 250 working days, once after each release.
- Even at release time, "what happened" is up for debate. The discussions at release time are not typically "what revenue streams have we opened up" or "what operational savings have we made." Those discussions will happen months later after everyone finishes figuring out whether the problem was "the requirements were wrong" (business stakeholders fall on the knife) or "the estimating was bad" (IT takes the fall). Then the people who have to make the partially finished software meet their needs figure out the manual workarounds, and everyone goes back to working in the dark until the next release. In a waterfall world, most stakeholders spend most of the time in the dark. In companies running even one agile project well, outcomes and productivity for that project can be measured tangibly and accurately the majority of the time.
So stop being such a wuss. Embrace the challenge. Own the factual changes you can create. Own the techniques you can bring to the people who want to hear about them. And own your ability to bestow actual power to your clients, and the value that power brings them. In the end, this is the only way to measure your effectiveness. And seriously, wash your hands after occupying a used bean bag chair. It's flu season.
Comments
Post a Comment