Has Agile Let Us Down?
Are developers really the bottleneck?
In a recent meeting, a senior executive asked a product manager why they couldn’t deliver more of the features requested for an upcoming quarter. The PM replied, “I would, if I could just get another four developers.”
After 20 years in tech, across a wide array of web & mobile front- and back-end technologies, with everything from tiny startups to established, 200-year-old enterprises, I’ve seen this pattern emerge consistently – the underlying assumption that software development is the blocker.
And increasingly over the past 10 years, there’s been this hope that Agile would finally fix that problem.
I believe that software engineering shortages are not a cause but a symptom. We’ll look into where the real problem lies, why asking Agile to fix the problem has created more issues. and where I believe the real solution lies.
Product teams are tasked with delivering from time-sequenced roadmaps, typically made of a random series of stakeholder commitments. Planning is done in advance either every quarter (if teams are lucky), or up to a year or more in advance.
After months of requirements gathering, when the work finally comes to the product team for action, it’s either been elaborated too far in advance in isolation from the team, or cryptically vague. Stakeholders then decry that teams aren’t moving fast enough because they’re unable to get these requests built and delivered at their arbitrarily-dictated roadmap cadence.
Agile to the rescue?
Agile was tapped by the enterprise for one reason – To fix the development team’s efficiency problem. Note one of the original Agile Manifesto signees, Jeff Sutherland, gained notoriety a few years back with his book and associated TEDx talk touting Scrum as the way to get your teams to do “Twice the Work in Half the Time.” (i.e., 4X the work…?)
This is absolute catnip for executives and stakeholders of all stripes tired of waiting for their pet projects to get delivered. So the goal of Agile in the Enterprise has really been focused on getting teams super-efficient to pushing out everything on their roadmaps.
Why are teams being asked to build these things?
With this sole focus on efficiency, and building and delivering “stuff,” that no one has thought to question-
- How good are these ideas? Are they as good as we think they are?
- Will they really make our clients happy and successful?
- How will they contribute to tangible business value?
Set Up to Fail
Given this dynamic, even when product teams are delivering efficiently, all kinds of worthless things that clients will never use can get quite efficiently pushed out the door. Worse, the really important things that clients really do need are getting missed because large enterprises tend to organize around internal silo structures, rather than end-to-end client experience value streams.
Without that client experience-centricity, it’s only natural that key pieces get over-engineered while other critical gaps occur.
And when things do go off the rails, IT continues to put product teams under the efficiency microscope (burndown), while “the business” plows ahead in isolation on an unending stream of disconnected feature request ideas, stocking roadmaps stretching off into the future.
But if the team has just shipped 2-3 features with their latest release, and one of them has not only negated the other two, but beyond that, caused entire critical segments of their user base to get frustrated and churn, what should happen then? And who’s supposed to be tracking that and take corrective action?
Product focus to the rescue
I’ve become increasingly convinced that enterprise embracement of a product focus, versus a legacy project focus, can provide a clue.
As leading product- and design-driven companies like Netflix, Amazon, and AirBnB demonstrate, the goal of modern software development is never on problem-solving over delivery, where the best teams drive a continuous organization-wide learning process, where savvy leaders strive to optimize for effectiveness, build just enough to learn from, and continuously Iterate.
What gets managed in Product Management?
Product managers manage neither the development team, nor their work. Yet without a Product Management focus it’s impossible to provide holistic meaning and clarity around what teams should be building, when, and why.
Not Just Competing Stakeholder Requests, but the Unfolding of a Vision
Instead of efficiently pushing out lists of features in isolation, product-driven teams are focused on the higher-level organizational vision – how does that flow to strategy, and how can teams continuously deliver on that strategy by delivering on measurable, data-driven changes in user behavior.
IT Project vs. Product Focus
Now take a step back and remember how IT tends to view their mission – they’re a
- Cost center
- Managing Projects and Resources to
- Deliver Features
- Incentivized for an
- Binary feature delivery model (ship=1=good)
While the Product Organization seeks to be is teams of
- Vision- and business-strategy-led
- Value producers
- Leading Products and People to
- Deliver Business Outcomes
- Incentivized for an
- Empirically data-driven,
- Problem solving model (customer behavior change+positive business value impact=good)
Asking a New Question first
So Agile hasn’t really let us down, so much as been the wrong question to ask the entire time.
Before putting pressure on Agile to optimize delivery at the team level, companies should focus on an enterprise-wide client experience product focus, which will open the door to a strategic product emphasis on delivering more rewarding user experiences as well as better business results.
The Unifying Power of Product
A truly empowered Product Organization can take a unifying vision and strategy, break that down into data-driven leading indicators of client behavior and discover how best to drive them across the business with self-organizing product teams. With a data-driven focus on the right metrics, the most inspiring vision and insightful business strategy can get transformed into motivated teams building the right things.
When teams are finally empowered to focus on solving the few, highest-priority product-driven client experiences that drive business outcomes, rather than the many disjointed feature requests, there will always be enough development cycles.
“Negative – South Melbourne, Victoria, circa 1934” by Kerr Bros Studio is licensed under CC PDM 1.0
Posted on February 27, 2016
In much the same way that special teams can quickly improve a football team, defensive design can make a big difference by taking control of decisive, transitional moments.
I’ve heard it said that to have a better overall listening experience in your home stereo, it’s important to focus & spend your money in those areas where the signal transitions from one format to another (music storage system >> electronics >> sound waves)
By the same token, I think you can do much to improve a mobile app or web experience by focusing on those critical moments when things go wrong.
Offensive Design Choice – the Heavy-Handed Onboarding Flow
Frequently, you’ll see coach marks or a tutorial as first-time users try to start using an app. The idea is certainly logical, but these approaches tend to get in the way of the user’s intent. They just want to get started using the app, poking around, and accomplishing their goal. If you need to put a whole tutorial on how to use your app, chances are, your app will not be used that much.
The Defensive Design Prescription – Prepare the User’s Experience with Care
In the same way that most reviews are written based on negative experiences, get ahead of your users with defensive design and put a plan in place to step up in the decisive moments.
- Onboarding – How simple can you make it? Can you resist the marketing team’s desire to capture more analytics?
- Registration – Can you use social login? Make clear that this is separate by sharing to the service
- Calls to Action – Don’t keep the user guessing about how to accomplish their goals on any given screen, or at every interaction fork in the road. Make it unambiguous.
Spend the lion’s share of your time thinking through user goals and intent. Create cushions through established patterns and quick safety release valves. Allow the user to recover easily and quickly.
In that way, you’re taking care of what you need to make things right up front, instead of having to try to fix things that are broken for the rest of the experience.
Posted on January 10, 2014
Here’s one from the archive – my old friend Minter Dial, former global head of Redken, former executive at L’Oreal, current globe-trotting consultant on digital strategy, did an interview with me towards the beginning of my tenure at Usablenet.
Granted, my perception right now has a great deal to do with working at one of the premier mobile web companies in the space, but for me, it’s no contest – I think that mobile web is where companies should be investing their money.
Not every phone will have or can even download your app, but every phone has a browser.
Posted on August 17, 2013
Who’s the customer for Google’s products – before you answer, take a moment to think how much you’re paying right now for
- Phone Calls
Not really much at all, thanks to Google, and just a few of its many products.
So if you’re not the customer, then who is? Why does Google build all of this great stuff?