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

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…

Requirements Traceability in Agile Software Development

One of the grim proving grounds for the would-be agile business analyst (henceforth "WBABA")  is the "traceability conversation."  Eventually, you will have to have one.  You may have seen one already.  If you haven't, you may want to half-avert your eyes as you read further.  It gets a little brutal.  But if you close them all the way, you can't read.
WBABA: in summary, we complete analysis on each story card, and then we support the developers as they build it that same iteration!Corporate Standards Guy:  but how do you do traceability in agile?  You have to have traceability.  It's broadly recognized as an important factor in building rigorous software systems. These software systems permeate our society and we must entrust them with lives of everyday people on a daily basis. [The last two sentences are an actual quotation from the Center of Excellence for Software Traceability website!] WBABA: [cowed silence]Corporate Standards …

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…