Skip to end of metadata
Go to start of metadata

Intro [3]

Agile methodologies seemed like a good idea to this software development team. But when the company doesn't sincerely accept the change in work style, the result is just a buzzword for the usual project hell, as Charlie Martin's story about an agile project gone wrong describes:

Sometimes, your friends tell you hard things. If you think you're doing Agile, you must step back every so often and ask: Can I respond to changing requirements easily? Do I have confidence that I could run the current build and see part of the system work? Am I seeing my family on a regular basis? Or did we plan to work overtime over Christmas to make our commitments? If you aren't seeing easy response to change, regular working deliveries and a regular schedule with a normal workweek, you have a cargo cult...

Cargo cults developed in Melanesia, starting in the 19th century, but really grew during World War II. To the locals, the war meant cargo planes and cargo ships arriving, carrying everything from canned pineapple to Quonset huts. And it was good... Then the war ended, and the cargo stopped. The locals responded by building their own runways, with airplanes made of bamboo and palm fronds, in hopes of attracting it back.

Martin's experience relates to a project that wanted to follow agile principles, but also had to fit into existing corporate standards and processes. Some agile principles were compromised, and although the project did deliver, it was late, cost more than anticipated, and was not much different in the end from a traditional waterfall project.

What does a cargo cult agile shop look like? [1]

From the outside, it may look a lot like an actual agile shop. After all, a cargo cult shop is imitating what they have seen about agile. However, like waterfall proponents, cargo cult agile shops are led by people who have looked at pictures of agile models, "read" agile books, or "learned" agile development from PowerPoint presentations. Perhaps there are a number of developers who know agile, but they may not be able to move the company towards agility in the face of generations of managers and developers who have been indoctrinated by DoD-2167.

By definition, agility describes an ability to respond to changes. As such, any agile process is going to have some sort of iterative process in which the software is improved and responds to any changes that have occurred during development. In a cargo cult shop, keep a particular eye out for iterations that don't include tasks other than programming. If the details of analysis, design, and testing are excluded, you are probably looking at a "cowboy" project or a waterfall project in disguise. An iteration should always include or consider changes. While possible, it is unlikely that the project will remain completely unchanged after an iteration.

With any agile process, the speed and effectiveness of adapting to change is the primary measure of how agile your team has become. If you are using an effective agile process, responding to change should be graceful. If a change causes a lot of disruption, or re-visiting a line of code that someone has already typed causes alarms to go off, you may be in a cargo cult.

If you are looking at a potential agile company, look at their process in as much detail as they will allow during the interview. If they use XP, ask to look at story cards. Do their unit tests actually test the functionality, or are they a check box to get past a sign-off? Are the story cards simply a requirements document created in one big design up front or do they add, change, and remove cards as they get further into the project. On a scrum project, ask how long a typical scrum meeting lasts. If their idea of a daily scrum is two hours, run, don't walk, to your next interview because they have missed the point entirely.

If you are already in a cargo cult agile shop challenge your process. Good agile process encourages a constant feedback loop regarding both your product and your process. If an agile process isn't working look into why and fix it. Go past the powerpoint presentations and the diagrams. Reproduce the results that created the processes you are attempting to emulate. If the agile process is printed and bound, and they haven't made a single change to it in five years, it is highly likely they have not challenged and enhanced their process to fit their people.

Some agile models are a toolkit and give guidance on how to effectively use them, while other methodologies require practices to be used together to achieve a result. Some practices stand on their own while others may be interdependent. Understand the benefits and consequences of cherry picking from agile, especially if you are doing a project waterfall style.

Agile as a Cult [1]

I am a fan of agile development in general because the Agile movement formally questioned and rejected the dogma of how software development should be done and, in particular, challenged the continuously failing waterfall model. Agile is just a step along the way and isn't without fault and dogma itself. We sorely need to keep moving towards improving our understanding of successful software development.

Post-agilism is starting to take hold with a tempered view, absent much of the hype and absolutism that has formed in some Agile communities. I look forward to the thoughts of these people who refuse to be constrained by dogma and continually challenge how we write software. It is this sort of skepticism that I think Feynman is looking for when he says we must not fool ourselves.


glossary glossary Delete
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.