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
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.


Popular posts from this blog

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.

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 applicable) and your analysts at the beginning of the project, as always, b…

The Agile Business Case

Many agile teams have never seen a business case, ever, and they may even be proud of it.

Our mantra is that we deliver "business value," not just "software," quicker, better, and faster, but if so, we certainly don't spend a lot of time reporting on value delivery, and in fact we may be scornful about "analysis paralysis."  As software developers, we consider ourselves to be doing quite well if we can deliver the software every two weeks (or continuously).  And this is particularly if we've enabled this frequent high-quality delivery through automated testing and automated build-and-release techniques.  We've reduced business risk by making results visible more often, and allowing the business to change direction more frequently.  We assert that along the way of course we're also delivering value.  But how would we prove it?

I've recently posited that we shouldn't even think of doing agile projects without capturing and recording s…

How To Write A One-Page Proposal to an Executive

One day you may need to communicate with an executive. Pro tip 1:  executives do not have time for you to dim the lights and show them forty slides with charts composed of animated dancing leprechauns and flashing arrows that emerge from the void in a checkerboard pattern. Pro tip 2:   Guys, and gals with deep voices, executives also don't need you to use your "Radio Announcer Voice."

As a rule, what executives want is simple: one printed page. No matter what it is, it should be one page. And it should be printed, not emailed.  You should plan to hand it to the executive, and then you should be quiet when they read it and wait for their questions.  It's harder than it sounds.
 So how do you do it?  Here are the steps:
Write the deck that expresses your proposal in as many slides as it takes.  Use imaginative animation and blinking letters if you must.Remove your title slide.Insert a new slide at the front of the deck with "Appendix" written on it in big …