Agile Monkeys Gone Wild

One of my favorite readings on Agile is Barry Boehm and Richard Turner’s now classic work “Balancing Agility and Discipline” [1]. In fact I made it a habit to revisit the book every once in a while. The prelude section features an interesting story about the elephant and the monkey. The story has a happy ending where the trusted elephant and the agile monkey join forces to serve their villages better. That’s really cool I say, but what if the monkey does not want to play? In other words, what if your village’s agile monkey wants to stay on the wild side and continue doing what iit is doing? What can your village do?

Extreme Agilists can present a real risk to any company developing software in an Agile manner. Working with people set on a particular model and unwilling to bend for the greater good of the whole could be particularly challenging for teams in the process of transitioning to an Agile method.

From my experience there are at least two major drivers for an extreme Agilist behavior. The first is the failure to link technical and methodology objectives to the business objectives of the company. This scenario usually happens when the Agilist takes the team into a pre-cooked method or solution with little regard to the real objectives of the company, such as markets, competitors, product positioning and overall strategy.

The second and perhaps more important driver is the over-emphasis on Agile methods rather than fundamental software engineering practices. A typical example of the latter is the way upfront design and architecture is handled in certain Agile methods. It is easy to fall into the trap of assuming that very little or no upfront design is going to work, just because of an Agile method. The reality is that in most cases the architecture does not evolve on its own and it needs a certain babysitting from the architects and the team. There needs to be balance of upfront architecture plus evolutionary design to achieve a middle way of delivering solid architecture in the final product.

So, what can the village do if they have to deal with a rogue agile monkey? They can start by talking about the real purpose of the project and the team’s existence. They can make it clear that most companies in today’s world cannot afford to subscribe solely to any particular platform, technology, or methodology. All of these are tools in the company’s disposal to achieve its final objective. Companies today pick their tools based on their short and long term business vision and the toolset should reflect that.

Finally if nothing else works I recommend the village elders get together with the monkeys and tell them the story of Babel. Per Frederick P. Brooks Jr. [2] despite that the project had a clear vision, plenty of manpower, adequate technology, lots of materials and enough time, it still failed. The project was a big initiative for its time. In fact, according to the Genesis account, the tower of Babel was man’s second major engineering undertaking, after Noah’s ark. But Babel was the first engineering failure.

Babel failed in two respects—communication and organization. The man were unable to talk with each other; hence they could not coordinate. The lack of communication led to disputes, bad feelings, and group jealousies. Shortly the clans began to move apart, preferring isolation to wrangling.

The village elders should talk to the agile monkeys and try to persuade them to play with the elephant. The alternative would be isolation and that could ultimately lead to the failure of the project.

References:

[1] Balancing Agility and Discipline: A Guide for the Perplexed, Barry Boehm, Richard Turner - http://www.amazon.com/Balancing-Agility-Discipline-Guide-Perplexed/dp/0321186125

[2] Mythical Man-Month, The: Essays on Software Engineering, Anniversary Edition, Frederick P. Brooks Jr. - http://www.amazon.com/Mythical-Man-Month-Software-Engineering-Anniversary/dp/0201835959