The Pattern of Mutually Assured Failure

The article found here provides very nice coverage of some of the real challenges of an agile transition.  Unfortunately, I did not notice coverage of the issue raised by someone's unhappy client in the quote at the top of the page.  Re-quoted here:

Agile consultants ruined the software group I work in. Making good software is hard, and anyone claiming to have a magical process that guarantees good software is selling snake oil. I can appreciate your wanting to make a buck, but would also seriously appreciate it if you could find some other industry besides software development to go screw up.

– an "Anonymous Agile Victim"

Sadly, there is an overabundance of coaches, consultants, and ScrumMasters who do not yet have enough experience to be guiding organizations through these dangerous seas. Yet these coaches are naturally anxious to gain that experience.

We can't pin this entirely on either party: It seems to be an agreement of Mutually Assured Failure. (And I'm not talking about the "Good, Lean Startup, fast feedback-loop" type of failure here. This is the "months wasted, everyone's angry, personal reputation in ruins, 'Agile' is a four-letter word" type of failure.)

Coaches need to be honest and professional about their levels of experience, and not be in a big rush to be the sole "Agile Guru" (Gah! That left a bad taste in my mouth!) at the organization.  Large-scale Agile transitions require at least two coaches (internal or external), both willing to risk getting canned (aka fired, dismissed, given the boot...) by surfacing uncomfortable truths to the execs, and both covering each other's blind-spots; be they experiential, technical, political, or cultural blind-spots.  They also need the support of at least one relatively high-level executive, and need to be conversing with that exec on a regular basis.  And that's just two of the ingredients needed to get started.

That was how I gained the needed experience on my first two large-scale Agile transitions:  First, in 2005-ish at Vanguard, then in 2007 at Salesforce.com:  Both brought me in as the team/technical coach and "guy who has actually worked on Agile teams for most of a decade." Both included an executive coach (e.g., Pete Behrens, who spent a lot of his spare time coaching me, as well as half the teams. Thank you Pete!)

Organizations are unwittingly complicit in Mutually Assured Failure:  They often see "Agile" as a cost-cutting mechanism, and use their own cost-cutting mindset to hire the least expensive coach they can find (akin to hiring the cheapest surgeon to perform life-saving surgery on your own body).

If you hire inexperienced ScrumMasters, don't expect great changes overnight.  If you hire "Agile" staff-augmentation, don't expect them to lead you out of your self-imposed chaos.

Startups and TDD: Building The Next Big Thing with Disciplined Agile Engineering Practices

I've coached and trained so many start-ups who are in a later round of funding, or are building the next release of their software, and wish they had done things differently. Usually, I'm there to help them establish good Agile engineering practices (and help clean up the mess).

I understand the "just get it delivered" pressure on startups, and that they have to beat the competitors (both known and unknown) to market.  But I don't buy into the notion that excessive technical debt must be accrued in the first delivery. It's not necessary, because test-driven development (TDD), pair programming, continuous integration (CI) and other "Agile Engineering Practices" (a.k.a. "Scrum Developer Practices" a.k.a. "Extreme Programming (XP) Practices") all provide actual, tangible benefits; and much more quickly than most people expect.

In my developer courses, I often quote the Nagappan Paper:

The results of the case studies indicate that the pre-release defect density of the four products decreased between 40% and 90% relative to similar projects that did not use the TDD practice. Subjectively, the teams experienced a 15–35% increase in initial development time after adopting TDD.

-- research.microsoft.com/en-us/groups/ese/nagappan_tdd.pdf, Nagappan et al,  © Springer Science + Business Media, LLC 2008 

If I were seeing my fellow investors get that kind of return on investment, I'd want to get in too.  And early!

Of course, the choice of whether to take on technical debt or to "pay as you go" by adopting these practices from the start would depend on how long it takes for the practices to pay for themselves.  (And, yes, of course each has a cost.)

My friend and colleague, Arlo Belshee, and I were having a conversation about Agile transitions.  Arlo, like myself, is an old XP aficionado (at least, as far as I can tell...sometimes Arlo is hard to read), and we've both had amazing successes and wonderful experiences on full-blown XP teams.  I must have asked him which practices he would suggest the team implement first, assuming they needed to pick up these practices gradually.  He chose continuous integration and pair-programming.

I was a little surprised he didn't include TDD, because TDD resolves so many root causes of trouble on Agile teams. But his explanation won me over:  These two practices immediately provide very fast feedback loops and high-bandwidth communication for the team.

By emphasizing "immediately" I'm suggesting that these practices pay for themselves right away, so avoiding them because they appear costly is a poor bet.

In my own experience, TDD also starts to pay dividends almost immediately.  Even within my 3-day TDD course, many developers report that a single microtest caught something they could not have foreseen.  Software development has become too complex an endeavor to ignore the benefits of a comprehensive safety-net of unit-tests: It has eroded the Amazing Predictive Powers of most programmers.

One client who put all developers through the TDD course reported, after only about 4-6 months, that their latest release was the least defective release they had delivered in many years.  One developer said that a single trivial unit test had saved him from including a defect that would have crippled one high-end (i.e., $$$$) client, and he felt that disciplined TDD had likely saved him his job.

And by reflecting upon merely two of my own longer-term product development efforts that utilized XP, I can think of three cases where TDD+pairing+CI saved or made the organization a significant amount of money (at least $ 1/2 mil/year). Due to the malleability and maintainability of the software, our teams were able to accept a surprising, radical "mini Black Swan" user-story which:

1. Opened up an entirely new market in a non-English-speaking country.
2. Allowed doctors to more efficiently use our emergency-oriented software in their routine, day-to-day operations.
3. Allowed a handful of highly-paid specialists to regain over 60% of their work-week that was previously spent manually transforming and re-entering patient data.

Each of those events was a surprise triple-win (for the customer, the organization, and the team), and each occurred within 6 months of adopting CI, TDD, and pairing.

If these disciplines reap benefits after such short periods of time, then the accrual of technical debt is only appropriate where the product can be written "in a garage" in a matter of days, and an upgrade will never be necessary.  Such products may exist, and they may even be quite useful and profitable (e.g., perhaps a smart-phone app).  I've never been involved in such a product's development, obviously because there would be no need for my kind of training and coaching.  But if I were called in to help develop one of these from scratch, would I still begin with good Agile engineering practices?  Yes!  Because I do not know what the future holds for that product, and I'd want to build in quality and maintainability, just in case we had built The Next Big Thing.