Your Agile isn’t my Agile!
The Agile Zone is brought to you in partnership with JetBrains. Learn how Agile Boards in YouTrack are designed to help teams plan, visualize and manage their work in an efficient manner, with support for both Scrum and Kanban processes.
- True Agile is rarely practiced. I’m not even sure what this means so it is difficult to compare. The description seems to imply Agile is a good thing and the fact it is rarely practiced correctly is the bad thing. If so, then I disagree with the premise. More and more companies are turning to highly skilled trainers and coaches to help them achieve something that can be called Agile instead of agile. Of course, the alternative is, *cough* *hack* *gag* waterfall. Even if Agile isn’t practiced as much as I’d like, agile is practiced, and mostly without the caveats presented by the original author. Advantage: Agile
- Heavy customer interaction is essential. This is certainly true for OPTIMAL results. Just as it is true for any waterfall project. One of the leading success indicators for projects of any type or size is customer involvement early and often! Both sides win when this is the case. Advantage: neither.
- Agile thrives with co-located teams. This statement is absolutely true. Co-location will help Agile teams a lot. Co-location will help waterfall teams as well. However, waterfall teams will not take full advantage of the situation because their interactions are fewer. If a team is not co-located I believe both Agile and waterfall teams will suffer equally. In many cases the waterfall suffering will be worse because things can fester for longer before it matters. Advantage: Agile
- Agile has difficulty scaling for large projects and large organizations. I’m not even going to give this one any credence by answering except to point people to Scaling Software Agility, The Enterprise and Scrum and numerous other books and papers on the topic. Agile scales at all levels just fine. Waterfall on the other hand… what is the percentage of large waterfall projects delivered on-time? Oh yeah, that’s right – nearly none! Advantage: Agile
- Agile is weak on architectural planning. I’m going to say it is harder in many cases to do architecture well in Agile. Teams struggle with the concepts. A big up front design is easier to manage, but not necessarily better. I’m going to throw a bone to those who say “hard” is the same as “weak” and say… Advantage: Waterfall.
- Agile has limited project planning, estimating, and tracking. This statement is true, but… it is because it has been proven that having more doesn’t help! Waterfall has all kinds of project planning, estimating and tracking and things still don’t work well. Advantage: Agile
- Agile requires more re-work. Studies show refactoring, when there is sufficient automated test coverage, is cheaper than overbuilding up front. Agile does seem heavy on refactoring. However, I’d rather refactor prior to release than release the wrong thing! Advantage: Agile
- Challenges making contractual commitments. Agile contracts are difficult to write well and difficult to get customers to agree to use. They are possible and many companies are being successful with it, but until there is more work done in this area I think it remains a bit of a sticking point. Advantage: Waterfall
- Agile increases potential threats to business continuity and knowledge transfer. Light on documentation simply means the appropriate amout of documentation is written rather than too much documentation. Advantage: Agile
- Agile lacks attention to outside integration. The detail the author provides for this one is just misleading and wrong. A good Agile team will identify technical risks early and address them. In addition, integration points would be clearly defined and encapsulated in some way if possible so late integration would not hurt anyway. Advantage: Agile
As you can see, Agile is the winner. I did give a couple of rounds to the competitor, but mostly because they are difficult concepts to master, not necessarily because I think waterfall handles them any better.
Until next time I’ll be Making Agile a Reality® for my clients by helping them utilize real Agile, not something based on myths.