Agile is a Cop-Out?

DZone 's Guide to

Agile is a Cop-Out?

· Agile Zone ·
Free Resource
In a blog entry entitled "Agile Software Is A Cop-Out, Here’s What’s Next", Forrester's Mike Gualtieri makes some bold statements about what he sees as hype and a lack of empirical evidence of success from the Agile community.

Now, Mike's post is bound to raise the hackles of many people in the Agile community, but I do agree he has some good points.

He doesn't specifically use the term "hype", but certainly the promise of hyperproductivity coming from Agile thought leaders like Jeff Sutherland doesn't help.  I have witnessed trainers routinely telling their students to expect incredible gains in productivity once they drink the Scrum kool-aid.  It's a great sales pitch - others are doing this and if you aren't achieving those sorts of increases then you must need more training or coaching!  The amount of Bad Agile or Bad Scrum that has resulted is a testament to both the hype that has pulled people into trying Agile and the difficulty in actually doing it well.

I will defend the authors of the Agile Manifesto, though, in that they were making a statement about the world of software development as it was in the late 90's and into early 2001.  Mike cites Steve Jobs using "insanely great" to describe products, but in February 2001 the world still hadn't seen it's first iPod.  OSX was a month away from going GA.  The aluminum-cased MacBook Pro and MacBook Air were 5 and 7 years away respectively.  The iPhone was a pipe-dream.  Tablets had come and gone several times at that point, long before the iPad was developed.  So, most of that insanely great design was still well ahead of us when the Manifesto was written.

Also, as an industry we sucked at building software, and the dot-com boom hadn't helped much to fix that.  You had either code and fix or some hard-ass waterfall process to follow, and precious little in between.  It's no wonder that the Manifesto's authors focused on that problem.  "Working Software" wasn't narcissistic, as Mike states, it was something that was sorely lacking in early 2001 (and arguably still is today).

Mike mentions that he first wrote about his approach, Parallel Immersive Software Studio (he acknowledges the acronym that creates!), in 2008 and has refined the ideas since then.  Well, the software development world is a little different today than it was in 2001.  The success of the products from Apple are mainly due to the total user experience, which is something that has grown and been refined over the ensuing decade.

I see a lot of good ideas in Mike's approach.  I certainly agree fully with the ISS parts of his approach, but I do have issues with Parallel.  Any time that groups go off in isolation to work in parallel, you incur multiple risks:
  • One or more groups go in the wrong direction;
  • You have to integrate the work at some point, and the longer you wait the more difficult the integration will be;
  • Based on Mike's description of parallel work, you are isolating experts in different areas thereby decreasing your Truck Number
Another point Mike makes is, "Parallel work streams can reduce uncertainty and the number of costly iterations."  Could I please see some empirical data to support that?  If he's going to criticize the Agile community for not providing empirical data, then I believe it behooves him to do the same.

Mike concludes the post with 5 key points about his process:
  1. Software is not code. It creates experience.
  2. Development teams are not coders. They are experience creators.
  3. Technical talent is “table stakes”. Great developers must be design and domain experts.
  4. Process is bankrupt without design. You get what you design so you better get the design right.
  5. Software is a creative endeavor, not an industrial process like building automobiles. The methodology is structured to support the creative talent.
I agree with all of these, although #4 concerns me.  What is Mike's definition of design?  What does it mean for a design to be 'right'?  How do you know when a design is right?  Is design ever done?  How much design is enough?

This segue's nicely into my growing interest in the Lean Startup community.  Lean Startup assumes you're going to use good engineering practices (many from the XP world) to build the software because they enable you to obtain the kind of rapid feedback required to refine a total product design into something for which people will actually pay money.  What I don't see in Mike's post is anything about that sort of validation - his process may ensure that you build some kick-ass, well-designed systems, but if you don't sell the product because you didn't realize that no one wanted it, have you really succeeded?

Mike has some very good ideas in his post.  I also saw some good ideas in a similar "post-agile" blog entry by Michael Dubakov.  While I don't agree with all of the points the respective authors make, I do think this sort of "what's next" thinking is healthy and will help make the second decade after the creation of the Agile Manifesto even better.

After all, reflection and continuous improvement are core concepts in Agile and the ideas put forth by Mike, Michael and Eric Ries of Lean Startup provide exactly that.

Whaddaya think?


Source:  http://practicalagility.blogspot.com/2011/10/agile-is-cop-out.html


Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}