Skip to main content

Next-Gen Agile: Demote the Non-Coders?

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:
  • '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.
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.
From http://lyricsdog.eu/lyrics/505397
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:
  • 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)
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.

Comments

  1. 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.

    But 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.

    ReplyDelete
  2. The problem with the Agile Manifesto (and with typical Agilists) is that they define Agility as a way they think we should work.
    This 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

    ReplyDelete
  3. 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?"

    ReplyDelete
  4. Personally, 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.

    I 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!

    ReplyDelete
  5. 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?

    Maybe we should update the Agile manifesto and state "Valuable and working software is the primary measure of progress"?

    ReplyDelete
  6. Bea, I fully agree with you! "Working software" would be better expressed as "valuable and working software."

    Roger, 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!

    ReplyDelete
  7. Roger,

    I 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

    ReplyDelete

Post a Comment

Popular posts from this blog

A Corporate Agile 10-point Checklist

I'm pretty sure my few remaining friends in the "small, collocated team agile" community are going to desert me after this, but I actually have a checklist of 10 things to think about if you're a product owner at a big company thinking of trying out some agile today.  Some of these might even apply to you if you're in a smaller place.  So at the risk of inciting an anti-checklist riot (I'm sorry, Pez!), I am putting this out there in case it is helpful to someone else.

Here's what you should think about:

1.Your staffing pattern.  A full agile project requires that you have the full team engaged for the whole duration of the project at the right ratios.  So as you provision the project, check to see whether you can arrange this staffing pattern.  If not, you will encounter risks because of missing people.  Concretely it means that:
a.You need your user experience people (if applicable) and your analysts at the beginning of the project, as always, b…

The Agile Business Case

Many agile teams have never seen a business case, ever, and they may even be proud of it.

Our mantra is that we deliver "business value," not just "software," quicker, better, and faster, but if so, we certainly don't spend a lot of time reporting on value delivery, and in fact we may be scornful about "analysis paralysis."  As software developers, we consider ourselves to be doing quite well if we can deliver the software every two weeks (or continuously).  And this is particularly if we've enabled this frequent high-quality delivery through automated testing and automated build-and-release techniques.  We've reduced business risk by making results visible more often, and allowing the business to change direction more frequently.  We assert that along the way of course we're also delivering value.  But how would we prove it?

I've recently posited that we shouldn't even think of doing agile projects without capturing and recording s…

How To Write A One-Page Proposal to an Executive

One day you may need to communicate with an executive. Pro tip 1:  executives do not have time for you to dim the lights and show them forty slides with charts composed of animated dancing leprechauns and flashing arrows that emerge from the void in a checkerboard pattern. Pro tip 2:   Guys, and gals with deep voices, executives also don't need you to use your "Radio Announcer Voice."

As a rule, what executives want is simple: one printed page. No matter what it is, it should be one page. And it should be printed, not emailed.  You should plan to hand it to the executive, and then you should be quiet when they read it and wait for their questions.  It's harder than it sounds.
 So how do you do it?  Here are the steps:
Write the deck that expresses your proposal in as many slides as it takes.  Use imaginative animation and blinking letters if you must.Remove your title slide.Insert a new slide at the front of the deck with "Appendix" written on it in big …