SPHERE OF INFLUENCE, INC. – software studios and services
Thad Scheer
Agile gone bad
I like hearing about software development success stories, but as an engineer I actually prefer to study the failures. I’ve always thought that a big part of being an engineer is knowing the modes of failure inherent to your materials. In software the best engineers memorize how all the little stuff can break; for example what can go wrong with the SqlNativeClient or how does a hacker penetrate a Web Service? A person who knows the failure modes can design around them or debug them when failures occur.
Methodology can also fail. All methodologies and development processes have failure modes that we need to study. Therefore, I really like hearing about Agile failures.
This post is about an article that appeared yesterday in CIO Magazine, “When Agile Projects Go Bad”.
The circulation of this article on various forums has spurred an Internet dog pile against Agile. I guess most of my colleagues would expect me to defend Agile against this barrage, but I don’t think I will. The fact is Agile projects can go horribly bad. Do they go bad more often than non-Agile projects? No, but that’s not the point. The point is to understand how, where, and why Agile projects fail.
I don't want to repeat what other people are writing, so I’ll limit my points to those I haven’t seen elsewhere; except one… When an Agile project ceases to be “agile in execution” the result is usually a disaster. Many people made that point today, and I agree with them.
Agile projects go bad when:
1) More attention is put on project drama than product greatness. When the humans lose sight of a product’s endgame because they are occupied with bureaucracy, ceremony, rivalry, laziness, or whatever…then the project will go south. Politics naturally tend to run wild and become the center of mass if they aren’t contained. The answer is to fixate on the product and how customers will use the product.
2) Worker productivity has poor accountability. Like everything else, Agile depends on external driving forces to keep productivity high. Even with 2-week iterations, Agile teams can drag ass if they aren’t pushed.
3) Accountability for goodness is lax. Agile depends on having strong willed opinionated people who demand high standards of goodness in product design, architecture, and code. If something is introduced that doesn’t meet the goodness threshold, even if it passes unit test, how long before it is highlighted and corrected?
4) The customer designs the majority of the product. Yes, I’ve said it! Customer-led product design is bad. Design should be customer-centric and user-centric, but not customer-led or user-led. Great products arise from inspired product designs; users seldom have the design experience to drive end-to-end product design. Product development should emphasize a deliberate product design activity fixated on innovation, utility, and human experience.
5) Budgets and teams are too big. The fastest way to destroy a project’s chance of success is to over fund or over staff it. People work most efficiently in resource constrained environments.
6) People aren't deep diving the technology stack. If developers and architects aren’t at one with the technology stack then their production code will amount to serialized snippets swiped from codeproject, MSDN, and other places known for publishing less than robust “how to” advice.
7) Unit testing is the only testing. I love automated unit tests, but honestly if that’s the only type of systematic regression in use then deliveries are going to fail. Every system needs a combination of automated unit tests, automated acceptance tests, manual acceptance tests, and manual exploratory testing. Yes, it is immoral to use humans to execute procedural tests that a computer can do…making automation a good thing. But human testers are still essential.
8) Agile amounts to rearranging the furniture and holding hands. People in the Agile-biz can sometimes be obsessed with the arrangement of furniture, Obeya rooms, leaderless teams, self examination, and a bunch of other touchy-feely gobbledygook. Fixate on that stuff and you will fail. If your team is not 100% fixated on the product and how customers will use the product then your chances of failure are high.
9) No requirements. If a system has no requirements then any result will suffice. Every system needs some documentation of record that specifies “correctness” and “acceptability”. There is plenty of room to be flexible in how that documentation is captured, be it in a spreadsheet, requirements tool, text document, executable test framework, or something else – but it needs to be captured.
10) No releases to production. No matter how short your iterations, if you aren’t actually running in a production environment, model office, or some other high-intensity-close-to-real-world-environment then every day spent building software is a day spent getting further away from what your users really want and need.
11) The people in charge of the workforce are decoupled from the work. Said another way, content-free management will kill any project…but will kill Agile projects without prejudice.