Agile Doesn’t Have a Brain

This post was originally published to my newsletter subscribers (10k of them now). If you’d like to get these updates via email sign up here.

If you’ve never been to Stormking Art Center in New York, you must visit next time you’re in the neighborhood. Spread out over a massive field are enormous sculptures and installations that boggle the mind in scale, scope and creativity….like this 3-legged Buddah.

When the Agile Manifesto was conceived in 2001 it was designed to change the way teams approached software development. It wasn’t a reaction to too little software getting deployed. It was a reaction to the wrong software being deployed. Or software not being deployed at all. But something happened on the way to mass adoption. The reason why companies were “hiring” Agile changed. Early adopters were looking for better ways of meeting the needs of the business sponsors of the software. They sought tighter collaborations, greater involvement of stakeholders and short feedback loops to ensure what they were building met the company’s expectations.

Fast forward 15 years and Agile has become the de facto way most companies work — at least with their software teams. However the reason they choose to work this way has changed dramatically. Instead of looking for better ways to satisfy the business’ needs they are now looking for a faster way. We’ve traded in results for velocity. Teams are incentivized to ship as much as they can. Roadmaps are written. Commitments are made and products get bloated without a clear sense of whether any of these new capabilities are being used, are desired or add customer value.

Our products end up looking like this guitar. In fact you can imagine this to be the Microsoft Word version of a guitar. 95% of the “features” on this guitar are useless to 95% of the population. How do we know what we’re shipping actually adds value?

Agile, as it’s currently being implemented in most companies, has become a “dumb” process. It doesn’t have a brain. The feedback loops originally intended to inform next steps have instead become checkpoints to ensure we’ve completed what we agreed to 2 weeks earlier. There are many fallouts from this development. The one I want to focus on this month is prioritization. If the goal is to get features out the door as fast as possible then all features are equal. The “value” the organization is measuring is deployment. It becomes incredibly difficult to prioritize (I see this with my clients every week) because all that matters is deploying bug-free code. No one is asking whether one feature provides more value than another. As long as velocity counts are going up, management is happy.

Instead, agile teams need to put a brain on their agile processes by focusing on customer value. What does that mean? It means:

• Understanding what your customer is trying to accomplish with your system by interviewing them regularly
• Understanding what’s getting in the way of them being successful by analyzing their behavior on your system
• Using that information to drive prioritization of features
• Building in regular feedback loops (quantitative and qualitative) that confirm that our ideas did indeed add value
• Letting the right solutions emerge from the use of the system — don’t attempt to predict exactly how each interaction will best be served. Customer usage of early-stage features informs future iterations of those features.
• Leverage the agility of this way of working to change course (i.e., re-prioritize) when the facts disagree with your plan

There’s much more to this conversation than a short post can cover. I’d love to hear what you’ve done at your job to build better prioritization practices and put a brain on your agile process.

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

Book News

The 2nd edition of Lean UX is shipping! It’s trending well in several categories on Amazon. I recommend you check it out. Sense & Respond is our follow-up to Lea UX for the leaders looking to build companies and teams that support the approaches we advocate for in that book. It is available for pre-order now. If you end up reading one or both of the books, we’d be grateful for your reviews on Amazon.

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

Upcoming Workshops:

New York City — Feb 7–8, 2017–2-day Certified Scrum Product Owner Course with Jeff Patton. In September, we sold this course out. We’re planning another one next February back in NYC. Early bird tickets are on sale now. We’re already 40% sold out.

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

As always, if you want me to work directly with your company on training, coaching or workshops, don’t hesitate to reach out.