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

How Do You Vote Someone Off of Your Agile Team?

One of the conundrums of agile conversion is that although you are ordered by management to "self-organize," you don't get to pick your own team.  You may not have pictured it this way, but your agile team members are going to be the same people you worked with before, when you were all doing waterfall!   I know I wasn't picturing it that way for my first agile team, so I thought I should warn you.  (I thought I was going to get between six and eight original Agile Manifesto signers.  That didn't happen.). Why "warn" you (as opposed to "reassure" you, say)?  Because the agile process is going to reveal every wart, mole, quirk, goiter, and flatulence issue on the team within a few hours.  In the old days, you could all be eccentric or even unpleasant in your own cube, communicating only by document, wiki, email, and, in extreme situations, by phone.  Now you are suddenly forced to interact in real time, perhaps in person, with written messag

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. From http://www.yogawithjohn.com/tag/yoga-class/ 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 a

Your Agile Transformation Needs to Start with a Quiet Phase

From a really great blog post on agile adoption:  http://smoovejazz.wordpress.com/2011/02/16/an-agile-approach-for-adopting-agile-practices/ I've observed some different agile transformation patterns, and maybe you have too: Just Do Standups   (Shoot, then Aim):   some people feel that since you're "agile," you should just start doing stuff, like daily standups, and then build more of the the plan as you go.  Find a team and start doing some agile with them!  Start a revolution one practice at a time, one team at a time. Pros:   you're very busy from the start. Cons:   what exactly are you doing and why? KPI-Driven Change (Aim, then Shoot) : some people who have worked in large corporations for a while will tell you that to get the respect of the people, you need to start with a plan, support the plan with awesome printed and online collateral.  Then you "kick off," tell teams what to do, and measure them using "Key Productivity Indica