Agile Zone is brought to you in partnership with:

Bob Hartman has spent 30+ years in software development. His logic-based approach to development and quality was honed early in his career when he obtained Bachelors and Masters degrees in Computer Science from Rensselaer Polytechnic Institute. Over the past 10 years he has grown from being an early adopter of agile to his current status as a Certified Scrum Trainer (CST) and Certified Scrum Coach (CSC). He also remembers the pain of long waterfall development cycles and understands the human and business interactions necessary to achieve success regardless of development methodology. Bob is a DZone MVB and is not an employee of DZone and has posted 20 posts at DZone. You can read more from them at their website. View Full User Profile

Your Agile isn’t my Agile!

08.25.2010
| 3323 views |
  • submit to reddit
Have you ever had the feeling someone REALLY didn’t get it?  I had that feeling recently when reading this article about the supposed weaknesses of agile.  Some of the 10 points make a bit of sense, but what seems to be missing is what happens in a non-agile scenario with the same limitations?  I decided to write this blog entry to show what I think would occur and to do a bit of a bake-off between agile and non-agile teams for each point raised by the writer of the article.  So, without further ado – drum roll please – welcome to… Your Agile Isn’t My Agile.Let’s get right to it.  Starting with number 1 and ending with number 10.

  1. 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
  2. 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.
  3. 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
  4. 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
  5. 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.
  6. 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
  7. 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
  8. 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
  9. 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
  10. 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.

References
Published at DZone with permission of Bob Hartman, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Tags:

Comments

Emma Watson replied on Fri, 2012/03/30 - 5:57am

I’ve never understood why people use the fact that agile encourages close interaction with the customer to be a criticism. If you use waterfall but the customer is not really involved, will that project be a success? Nope. To me, the agile is about mindfully doing more things that promote project success and dropping the things that don’t. How can that be a bad thing?

Swing

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.