Agile magicfesto
Agile was never meant to be the silver bullet that consultants claim it to be or that which revenue-obsessed executives bet the farm on.
So then, here’s why you should call off your agile witch hunt and instead adopt a few simple changes to re-equip agile to be the delivery engine it was meant to be.
“Make us agile”
There were lots of long days at Partsearch, a consumer goods company I was the Director of Product at, back in the mid-2000s. On one particularly long day that turned to night, I was walking back to my office when our CEO stopped me in a hallway.
Frustrated with the pace at which our 75-person technology team was able to pump out new features and products, he charged me with transforming the company to adopt Agile.
I believe his words were:
“You need to make us agile.”
With mounting pressure to get more and more done, while constantly feeling like my teams had less time and too few people, I accepted his challenge.
Naturally, my next move was to google agile.
It was the first time I realized that everything I had been previously trained about building software at Accenture followed a waterfall approach.
Of course, this made sense given Accenture’s business model. You know… staff as many 20-year old consultants in client cubes, having them use software development methods that took as long as humanly possible to complete, netting the most profits Accenture could reap.
I became mesmerized with the promise of Agile helping to speed up delivery. I thought, “Aha! This is the silver bullet we need!”
Within a few weeks, and with the help of some pin-striping tape, I had converted a couple whiteboards into Kanban-style boards. I also managed to order several stacks of post-its, booked various teams in daily stand-ups, got buy-in for business stakeholders to join those stand-ups, and transitioned us from Microsoft Project to some weirdly customized implementation of Jira.
I spent the next 6 or 7 months pissing off my entire technology workforce.
I also helped to expose to the rest of the company just how inefficient our product development process was.
During our stand-ups and via the help of my executive summary burndown reports, it became obvious how much time & money we wasted building this week’s priority 1AA feature, only to stop midway, shift to priority 1AB, stop again, and start over on something completely unrelated.
6 months later, I was fired and Agile was widely considered a failure. Not the greatest ending. However personal relief came for me when the company filed bankruptcy 12 months afterward… not because I’m a dick, but because it confirmed that me, Agile, and my crazy-looking whiteboards were not to blame. But they also didn’t help.
Agile mania since then
Since my days at Partsearch, Agile went on to experience its golden age, followed by its decline.
Nowadays, if you search for agile, the more popular pieces of content are from those sick of hearing about it, confused how it relates to lean / design thinking / design sprints, or have some new flavor to add to the other 40 versions that already exist.
Of course, consultants and training institutions haven’t helped. Their fingers are in every crevice and conversation related to agile. There are 23M results for agile certification.
When a methodology becomes associated with gurus, greed, and practitioners compelled to add letters to the ends of their names to acknowledge their agile authority, people should be entitled to throw things.
But that’s just it. It’s not agile itself that’s the problem. It’s what people have done to the practice in the name of earning a buck.
I like how Teresa Torres puts it:
“Again, this isn’t a problem with Agile. It’s a problem with people’s interpretation of Agile.
Agile simply encourages you to build iteratively. The concept of an MVP is to build the smallest product that validates your biggest assumption, not to build the easiest / quickest product.”
As for me, I’m definitely 1 of the people sick of hearing about agile, but not because it’s broken or dumb or consultant snake oil. Agile is actually a phenomenal approach to building software. It’s just not the only nor the most important aspect of building successful products.
Marty Cagan nailed it when he said:
“It’s important to understand that Agile really doesn’t tackle the hard problems. Don’t get me wrong; you should be running some form of Agile, but it’s just a delivery process.”
What’s wrong with better, faster delivery?
Nothing. But also everything, if that’s what you’re spending all of your company’s vbucks on.
The problem is that we place way too much emphasis on traditional forms of progress. In the world of software development, that equates to lines of code and screen mockups.
All of our roadmaps and timelines are tilted heavily toward doing stuff, aka delivery.
But when it comes to discovery; e.g. research, problem framing, prototyping, and overall learning about the problems we’re solving, there is one objective: get through it as quickly as possible.
For example, we had an enterprise customer ask us to help them on a multi-billion dollar market opportunity. The total product development investment was going to be less than $1M and take 4 months to get an initial product to market.
The numbers were exciting to them, except they blindly asked us to reduce the time & budget we had earmarked for discovery: 6 weeks and ~$100,000. They decided that more time should be spent on building than to waste time researching what they already knew.
It’s the cultural mindset that’s off here. It starts at the top with the leadership team and permeates down to the summer interns you’re staffing. Discovery is not viewed as an exercise of value, but checking boxes. Discovery is seen as a vehicle for people to prove they were right vs. an opportunity to learn something new — including when to kill a bad product idea.
So, what’s wrong with better and faster delivery? If you accelerate the rate at which you build a stack of new features that nobody gives 2 shits about…everything.
Delivery, meet discovery
What’s missing, then, from the discussion companies are having strictly around agile, is the integration of proper discovery with delivery (i.e. agile sprints).
By bringing the rapid learning and validation that discovery brings to your delivery process, you’ll create more of a balance between doing the right things (discovery) and doing things right (delivery).
Design Sprints offer 1 route for teams in need of 1 of the more popular, time-boxed, and efficient discovery processes. In fact, some even refer to them as discovery sprints.
Additionally, from what I’ve read and talked with others about, Dual Track Development seems to be another choice for closing the gap between discovery and agile-fueled delivery.
So then, what follows are the top 3 shifts you need to make, in order to realize the benefits agile was intended to provide within a comprehensive product development practice.
Just please remember 1 thing — while initial discovery will precede your first delivery sprints, discovery is not a one-time event. That’s why I used the word integrate above; i.e. the learning that happens within discovery should happen throughout product development, including post-launch.
1. From solutions to outcomes
Because agile is a delivery structure, it makes sense that discussions within agile sprints are about solutions — still, hopefully with a curious mindset that initial sprints may (often do) fail but that you’ll learn and iterate quickly.
When it comes to adding in time upfront for discovery, the pitfall is to keep your research & testing discussions centered around solutions.
When everyone is focused on solutions, creativity and innovation grind to a halt. Instead, when people are discussing the outcomes they hope to achieve (e.g. increased conversion of new users), everyone can contribute and lots of different ideas flourish.
2. Speed increases, actually
If we use delivery-only agile as our only vehicle for product development, we adopt a misguided process of build > measure > learn. Misguided in the sense that you’d spend weeks or months building a bastardized version of an “MVP” in order to measure and learn.
That’s just downright stupid, and not what Eric Ries or Steve Blank meant.
Your first box to check is learning enough about the problem — who it affects, how it affects them, and how they solve it today.
For most problems, learning can come via fairly rapid qualitative research — talking with, interviewing, observing 5–10 highly targeted users. For more complex problems, or once your research has reached its limits, you can build a prototype to help continue learning until you’re ready to build & launch a marketable solution.
And because it’s much faster to learn via talking with users + prototyping and then building vs. building and rebuilding solutions over and over again until you’ve learned and iterated enough times, your overall product development gets faster.
Worst case: you learn early on and with very little investment that you should kill an idea.
Best case: you get to market faster, with a product that puts you in a better position to continue learning and growing.
3. Silos to squads
Agile is primarily a tool for engineering teams, which is fine. But then again, it doesn’t really do much to help with the flow of information across roles. This is what I learned at Partsearch.
Agile is perfectly fine with (i.e. it doesn’t attempt to challenge) the dynamic of stakeholders coming up with ideas, product managers defining solutions, designers designing those solutions, and, finally, engineers turning designs into working features.
In fact, this is the very definition of waterfall which agile looks to eradicate. In such a stage-gate process, we create silos where information, ideas, and collaboration go to die.
Additionally, such handoffs creates extreme forms of product ownership; i.e. the PM owns it or nobody owns it. In other words, PMs only own requirements and wireframes. Designers only own art assets and visual styling. And engineers only own working, tested code. And when things don’t work, fingers fly.
Instead, when you set your product teams up in cross-functional squads of stakeholders, PMs, designers, and engineers, all contributing to the idea of achieving a particular outcome and working through solutions, everyone is capable and committed.
The end result: discussions center on needs vs. answers, trust boons, and product ownership becomes inclusive and autonomous.
Ensuring design sprints don’t become the new agile
You’d think I’d have learned my lesson after the Partsearch agile debacle. In reality, we spent the first 6 years at New Haircut focused exclusively on improving our delivery process and becoming more agile — whatever that means.
Then, in 2015, a light bulb moment happened when we discovered design sprints. Because of design sprints — for the first time in our history and my 20-year career did discovery become understandable and actionable.
But just like we’ve learned with agile, discovery via design sprints are not a silver bullet, they won’t make bad ideas good, and sometimes it’s best not to use them.
You still need to put the work in to make design-sprint-powered discovery viable and valuable.
When you do, you’ll be doing your part to keep the intent of design sprints and, in larger part, discovery, aligned with its mission — to quickly and cheaply learn about problems you’re trying to solve, so that you can build more successful products, more collaboratively and in less time.
Wrapping up
The higher you climb, the harder you fall. Over the past couple decades, agile rose to the top. But misunderstandings and misuse led to its crash.
I hope this article helped you validate what you probably already knew — spending even just a bit of time doing high-quality discovery work will yield the delivery results you always hoped agile would produce.
