Mike Gualtieri threw down an enjoyable gauntlet this week with his Forrester blog post, "Agile Software is a Cop-Out, Here's What's Next" Gualtieri put some provoking words around two sentiments I've agreed with for some time, namely:
But what are we to aspire to, if we use the "cop-out" label on "working software," "customer collaboration," and "responding to change?" That would make us one for four, Agile Manifesto-wise. Here, I found myself less in agreement with Gualtieri. He proposes four new pillars to replace the four old ones:
What I was surprised by is that when Gualtieri says "agile is a cop-out," he doesn't mean that the original manifesto was too focused on the development point of view (at the expense of other team members and stakeholders), but instead, that developers should aim for more. They should stop being part of the cast, and take the heroic central roles they've always meant to have. The problem: '[d]evelopers often blindly rely on businesspeople, business analysts, user experience designers, and customers to tell them what will make a great user experience.' Gualtieri's solution? Developers should do user experience themselves and cut out the middle man!
Great software talent are renaissance developers who have passion, creativity, discipline, domain knowledge, and user empathy. These traits are backed by architecture, design, and by technical know-how that spans just knowing the technology flavor of the day.
Yikes, and measuring progress by "working software" is narcissistic? Moreover, how many people out there can actually be "best" at passion, creativity, discipline, domain knowledge, user empathy, architecture, design, technical know-how, all simultaneously, and while still holding a day job? I think I know one person who has six out of seven of these, but he can't design his way out of a paper bag, and gets help with that.
I had actually expected Gualtieri to take this somewhere different. Having agreed with his diagnosis that agile needs to be more than coding, and needs to take more interest in delighting customers, I had thought he might take this more in the direction of Jez Humble's Continuous Delivery or Eric Reis's Lean Startup, where small teams build towards compelling "delightful" customer visions by breaking down and testing ideas against actual customer use, and modifying to fit. The "definition of done" in this case isn't "deployed" but rather "deployed with an ability to do A/B testing and measure usage patterns to determine next steps."
Or, alternatively, I thought he might invoke Steve Jobs, so much in our minds these days, to say that having a single person of genius impose a vision with an iron hand is more important than everyone having a say all the time, and developers should have some respect for that concept.
Or indeed, I thought he might be going in the direction of Stephen Denning, whose appealing "Radical Management" corporate vision seems to meet Gualtieri's needs for Manifesto tweaking by spreading "the Wisdom of Crowds" all the way up into senior management, empowering small teams to come up with delightful products by getting executives out of the way.
Of course I agree with Gualtieri that a focus on "customer delight" appears to be an engine which can drive corporate success quite vigorously. And of course design by committee and an over-reliance on consensus leads to least-common-denominator solutions which maximize team peace and at the expense of measurable customer value. And of course coders should take some responsibility for entering into discussions about design visions or user interactions, and not require minute written instructions. But I would picture getting to "customer delight" as being a process of refactoring the way teams work together, and perhaps elevating our joint respect for user experience designers as people with distinct skills not available to the entire general population. A coder can be an experience designer but need not be (and vice versa). Let's just make sure there's always at least one on the team.
- 'Using "working software" as the measure of progress is narcissistic,' since it focuses on what developers are interested in (the software), not what the business is interested in (the value the software brings to the business)
- It's a further cop-out to think 'that great software can be developed through a process of dead-reckoning with business people.' (the hyperlink is Gualtieri's). Incremental design by committee may be democratic, but it's not going to create any iPods.
 |
| From http://lyricsdog.eu/lyrics/505397 |
- Parallel (implement things in parallel, not serially)
- Immersive (developers should know the business, so they can build an experience, not just write some loops)
- Software (needed for completeness, since this is a new software manifesto)
- Studio (re-imagine software development as producing a customer experience)
What I was surprised by is that when Gualtieri says "agile is a cop-out," he doesn't mean that the original manifesto was too focused on the development point of view (at the expense of other team members and stakeholders), but instead, that developers should aim for more. They should stop being part of the cast, and take the heroic central roles they've always meant to have. The problem: '[d]evelopers often blindly rely on businesspeople, business analysts, user experience designers, and customers to tell them what will make a great user experience.' Gualtieri's solution? Developers should do user experience themselves and cut out the middle man!
Great software talent are renaissance developers who have passion, creativity, discipline, domain knowledge, and user empathy. These traits are backed by architecture, design, and by technical know-how that spans just knowing the technology flavor of the day.
Yikes, and measuring progress by "working software" is narcissistic? Moreover, how many people out there can actually be "best" at passion, creativity, discipline, domain knowledge, user empathy, architecture, design, technical know-how, all simultaneously, and while still holding a day job? I think I know one person who has six out of seven of these, but he can't design his way out of a paper bag, and gets help with that.
I had actually expected Gualtieri to take this somewhere different. Having agreed with his diagnosis that agile needs to be more than coding, and needs to take more interest in delighting customers, I had thought he might take this more in the direction of Jez Humble's Continuous Delivery or Eric Reis's Lean Startup, where small teams build towards compelling "delightful" customer visions by breaking down and testing ideas against actual customer use, and modifying to fit. The "definition of done" in this case isn't "deployed" but rather "deployed with an ability to do A/B testing and measure usage patterns to determine next steps."
Or, alternatively, I thought he might invoke Steve Jobs, so much in our minds these days, to say that having a single person of genius impose a vision with an iron hand is more important than everyone having a say all the time, and developers should have some respect for that concept.
Or indeed, I thought he might be going in the direction of Stephen Denning, whose appealing "Radical Management" corporate vision seems to meet Gualtieri's needs for Manifesto tweaking by spreading "the Wisdom of Crowds" all the way up into senior management, empowering small teams to come up with delightful products by getting executives out of the way.
Of course I agree with Gualtieri that a focus on "customer delight" appears to be an engine which can drive corporate success quite vigorously. And of course design by committee and an over-reliance on consensus leads to least-common-denominator solutions which maximize team peace and at the expense of measurable customer value. And of course coders should take some responsibility for entering into discussions about design visions or user interactions, and not require minute written instructions. But I would picture getting to "customer delight" as being a process of refactoring the way teams work together, and perhaps elevating our joint respect for user experience designers as people with distinct skills not available to the entire general population. A coder can be an experience designer but need not be (and vice versa). Let's just make sure there's always at least one on the team.
Mike's understanding of Agile is a long way from mine. In fact, I think his two criticisms seem to reflect the common but mistaken impression that agile development is unplanned and undisciplined, when on the contrary a true agile process requires a great deal of discipline.
ReplyDeleteBut the real problem is that his description of agile's two "cop-outs" fails to acknowledge the traditional engineering approach to software project management, to which agile is responding. He paints agile as an excuse for programmers to bury their heads in their code and ignore the real world, whereas in fact the principles of working software and daily interaction with the business encourage exactly the opposite!
Compared to the waterfall model, agile is a step forward, not a step back. That's not to say that we don't need to go even further, but the way to do that is certainly not by ignoring the benefits of agile and betting the barn on some fresh new methodology (e.g. "STUDIO") with absolutely no empirical basis.
The problem with the Agile Manifesto (and with typical Agilists) is that they define Agility as a way they think we should work.
ReplyDeleteThis is bad.
Agility should be defined by want we want to achieve: Better software quality, more user satisfaction, more economic success with our projects, ... and all this ia a world moving faster and faster.
You may want to read http://www.greiterweb.de/spw/Agile_is_not_Manifesto.htm
Thanks for your comments, Mike and ggreiter! The word "Agile" is almost like a Rorschach test these days--it means what you want it to mean. I agree with both of you that the real point isn't "what is agile," but "what is most valuable to do?"
ReplyDeletePersonally, I am agnostic on whether one should or shouldn't use Agile. I am also not particularly interested in what Agile really is. The one topic I have passion about is the topic of scalability. I'm interested in applying software development approaches to large IT projects. By large, I mean over $10M. And while it is not particularly clear to me what Agile is, it is very clear to me that whatever it is, it doesn't scale up to projects of this size.
ReplyDeleteI have had a number of conversations about this. Many (but not all) Agile practitioners disagree with my assertion that Agile doesn't scale. But I believe they are wrong. This can be proven theoretically and demonstrated pragmatically.
This doesn't mean that Agile is bad. Just that it needs to incorporate new ideas to allow it to move up into the large systems world. So far, I have not been very successful in engaging the Agile community in this discussion. Perhaps it can start here!
In any case, for more on the theory of scalability (the starting point for any discussions of scaling Agile), you might check my Web Short on "The Relationship Between Project Size and Failure Rates" available at http://www.authorstream.com/Presentation/RogerSessions-1204668-the-relationship-between-it-project-size-and-failure-rates/ and my white paper, "The Mathematics of IT Simplification" available at http://www.objectwatch.com/white_papers.htm#Math.
Thanks! And if anybody is interested in a discussion on Scaling Agile, I'm ready!
I always thought the business value aspect of Agile was a core sentiment - equal to "working software". Maybe others don´t see it that way?
ReplyDeleteMaybe we should update the Agile manifesto and state "Valuable and working software is the primary measure of progress"?
Bea, I fully agree with you! "Working software" would be better expressed as "valuable and working software."
ReplyDeleteRoger, I will gladly look at your article! One large irony of my life is that I do a lot with agile without ever encountering small collocated teams. So let's talk about that! More soon, I hope. Cheers!
Roger,
ReplyDeleteI agree that your approach to scaling projects at the $10M level and above is a really interesting one! I've definitely learned a lot just by looking at the white paper you cited, and your book, "Simple Architectures for Complex Enterprises," (2008) this afternoon.
I'm actually in violent agreement with you that the success or failure of a project occurs during the business case and the initial partitioning of a project into subprojects small enough to be adequately managed. I suppose you may have encountered Scrum purists who want to just "jump in," and who complain that you're creating a delay by overthinking. I do not number myself among that group, though, and lots of us don't think that way.
I personally intend to incorporate your ideas of correct partitioning in my own project and program management going forward. I've certainly seen SOA madness first-hand, and it's nice to know how to combat it better going forward. So think of me as a new fan, and best of luck to you!
Elena