This link was seen on a scrum-toronto list, referring to an e-book called Stealth Methodology Adoption. The title is brilliant, and reflects, in my view, a significant means of adoption of Agile technologies at this point in the maturity of this market.

A small straw poll of friends and family in the business indicated that they used Agile under the radar screen in more projects than not. Often, artifacts were translated into the artifacts of more traditional PMOs without a word of explanation.

This is a dangerous approach, however necessary at times.

The partial implementation of an Agile method, without buy-in in certain quarters can lead to a failure to realize the benefits of the method. If the practices that were used can be blamed, they will be. People love to find scapegoats, and there are costs to agile that can be pinned. For example, if the project fails, but TDD was used in isolation, or used badly, it can be held to account as having taken more time than just writing code. If Pair Programming is used in an otherwise traditional project that fails, it can be identified as a halving of productivity. If daily scrums and backlog are used (again, by themselves, or without experience), they can be seen as a failure to gather and/or manage sufficient requirements.

It take subtlety and wisdom to know how much Agile to put into an organization, how much visibility, and which particular practices will garner the most benefit in a particular area. Most agile methods have a combination of practices that encourage emergent behaviour. But in many cases, the practices themselves are emergent. The interaction of daily scrums with a scrum master that’s working the group to a sprint backlog, and working with a product owner to refine the product backlog for the next sprint – without interrupting the sprint – these have powerful effects on productivity when put together. But, for example, all you have to do is interrupt the sprint and start messing with sprint backlog, or have a product owner / scrum master that doesn’t do the work of refining a good product backlog and you end up with developers who don’t know which way to turn at a given moment.

Similarly, TDD – if you are writing tests first, but you’re not actually defining “done” properly, (ie. sufficiently covering the desired behaviour, edge and negative cases) then you can end up having someone write a lot of tests that are practically meaningless to the code in question. This means that you don’t get the benefits of the testing, plus you incur the costs not only of the tests, but also of the wasted time sifting through test code that was not written against the requirements of the interface.

In a lot of these situations, it is judgement that comes from experience that is the real solution. There are few formulae that can practically resolve these questions. The benefits of NOT implementing Agile in stealth-mode, therefore, include the ability to bring in experienced mentors who can provide this kind of judgement to an organization new to agile approaches. Most “stealth agile” projects don’t have budget for such. But books like the afore-linked can help communicate some of this wisdom and judgement.