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:
I found myself very entertained by this blog post. Particularly the "dead-reckoning" reference. Anyone who knows Johnny Cash's famous song, "One Piece at a Time," has probably thought of that song when first encountering evolutionary design.
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:
I think it's actually three pillars, not four, plus as Gualtieri points out wryly, the pillar names together build to an unfortunate acronym. But that's okay.
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.
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.