Skip to main content

3 Reasons Agile is Best in Cynical, Cutthroat Cultures

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!
From the excellent http://www.theculturedoctor.com.au/blog
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:
  • 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.
At every level in an organization delivering waterfall projects, executives live in a perpetual "prisoner's dilemma" of bluffing, finger-pointing, and turf protection.  From a pure game theory perspective, stakeholders who can base their message on more provable facts have more options--bluff or tell the truth?  When to tell the truth?  Let someone else really dig themselves a deep hole, and then sweep in with a surprise which is no surprise to you, the messenger?  This is powerful stuff, even when we as coaches do not see teams broadcasting their progress to each other with big posters over every cube.

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

Popular posts from this blog

How Do You Vote Someone Off of Your Agile Team?

One of the conundrums of agile conversion is that although you are ordered by management to "self-organize," you don't get to pick your own team.  You may not have pictured it this way, but your agile team members are going to be the same people you worked with before, when you were all doing waterfall!   I know I wasn't picturing it that way for my first agile team, so I thought I should warn you.  (I thought I was going to get between six and eight original Agile Manifesto signers.  That didn't happen.). Why "warn" you (as opposed to "reassure" you, say)?  Because the agile process is going to reveal every wart, mole, quirk, goiter, and flatulence issue on the team within a few hours.  In the old days, you could all be eccentric or even unpleasant in your own cube, communicating only by document, wiki, email, and, in extreme situations, by phone.  Now you are suddenly forced to interact in real time, perhaps in person, with written messag

A Corporate Agile 10-point Checklist

I'm pretty sure my few remaining friends in the "small, collocated team agile" community are going to desert me after this, but I actually have a checklist of 10 things to think about if you're a product owner at a big company thinking of trying out some agile today.  Some of these might even apply to you if you're in a smaller place.  So at the risk of inciting an anti-checklist riot (I'm sorry, Pez!), I am putting this out there in case it is helpful to someone else. From http://www.yogawithjohn.com/tag/yoga-class/ Here's what you should think about: 1.        Your staffing pattern.  A full agile project requires that you have the full team engaged for the whole duration of the project at the right ratios.  So as you provision the project, check to see whether you can arrange this staffing pattern.  If not, you will encounter risks because of missing people.  Concretely it means that: a.        You need your user experience people (if a

Your Agile Transformation Needs to Start with a Quiet Phase

From a really great blog post on agile adoption:  http://smoovejazz.wordpress.com/2011/02/16/an-agile-approach-for-adopting-agile-practices/ I've observed some different agile transformation patterns, and maybe you have too: Just Do Standups   (Shoot, then Aim):   some people feel that since you're "agile," you should just start doing stuff, like daily standups, and then build more of the the plan as you go.  Find a team and start doing some agile with them!  Start a revolution one practice at a time, one team at a time. Pros:   you're very busy from the start. Cons:   what exactly are you doing and why? KPI-Driven Change (Aim, then Shoot) : some people who have worked in large corporations for a while will tell you that to get the respect of the people, you need to start with a plan, support the plan with awesome printed and online collateral.  Then you "kick off," tell teams what to do, and measure them using "Key Productivity Indica