Sale or Adoption

James McGovern talks about failing to sell A/agile in the enterprise. While close, I believe the sales process is not at fault, rather, it's that path to adoption. Also, along with everything else, it's all truly about alignment with the business goals and strategies.

I've recently had the benefit of seeing the life-cycle of almost a dozen agile software development projects over the past year, some ranging through multi-year efforts. I have seen the victories, the failures and the in-between. I started noting some contradictory behavior between customer needs and agile practices, especially the more dogmatic ones. However, I didn't have sufficient data to make any good correlations.

One particular incident involved Test-Driven Development (TDD). In this case the dogma stated that TDD must be done. However, it was truly placing the delivery schedule in jeopardy. Moreover, the deliverables only needed to be good enough. Needless to say, a large rift developed dividing the dogmatics and the customer. Thankfully, the customer's needs prevailed and TDD was tossed and the product was barely delivered in time. This is only one such incident but, clearly the whole concept wasn't working as advertised.

A couple of weeks ago, I stumbled across this paper about software process adoptions. 7 years ago, someone has already thought through this. Bringing back the TDD example, trying to apply a technique that emphasizes quality when the real strategy is innovation (where customers willingly trade quality for newness!) is completely counterproductive. That is, avoid prescriptive processes that require discipline when quality is not the business strategy. Clearly, no matter how hard we try to sell agile, we will fail. Why? There is no logical path for adoption.

Don't sell agile!

To quote a colleague, "Nobody buys Toyota trucks because of the TPS and lean manufacturing."