Why Agile Isn’t Working and What We Do Differently
UPDATE: We’ve written an entire book on this topic! Read it online: Shape Up: Stop Running in Circles and Ship Work That Matters.
Agile started off as a set of values. Values are subtle and abstract, so as agile spread, what spread wasn’t the values but the practice of working in cycles. Cycles are easy to explain and easy to copy.
People in our industry think they stopped doing waterfall and switched to agile. In reality they just switched to high-frequency waterfall.
Agile became synonymous with speed. Everybody wants more, faster. And one thing most teams aren’t doing fast enough is shipping. So cycles became “sprints” and the metric of success, “velocity.”
But speed isn’t the problem. And cycles alone don’t help you ship. The problems are doing the wrong things, building to specs, and getting distracted.
Claiming there’s a True Agile™ somewhere in the past or future doesn’t help either. When your team struggles with shipping, you need practical steps you can apply here and now. Not just an ideal.
Cycles are good. We work in cycles at Basecamp. But in addition to cycles you need three other practices to ship on time and in good health.
Deliberate resource allocation
Designers and developers can’t make progress if people constantly pull at their attention. It doesn’t matter if support finds a bug or sales needs a new feature. Allocating resources means dedicating resources. Whoever allocates the time and money to build a feature must also protect the team so they can do what was asked. It takes a mandate from above to secure the team’s time and attention. The team is doing this and only this during the cycle.
At Basecamp we start each cycle of work with a team of three: one designer and two programmers. They have nothing to do but this project. If you feel you must fix bugs the moment they arise, then dedicate resources for that. If you have tension between sales and product, make a choice for this cycle. If you don’t have enough people, rotate cycle time among departments.
Only management can protect attention. Telling the team to focus only works if the business is backing them up.
Mutable requirements
If a team works to a spec, there’s no point in iterating. The purpose of working iteratively is to change direction as you go. Defining the project in advance forces the team into a waterfall process. If every detail of the plan must be built, teams have no choice when they discover something is harder than expected, less important than expected, or when reality contradicts the plan.
At Basecamp we kick off each project with a core concept. We do our homework on the strategy side to validate that some version of the idea is meaningfully doable in the time we’re allocating. We’re also sure that less than 100% of the concept will ship. Not everything will make it but the important things will. If we aren’t sure, we’ll slot something else into the cycle and come back when we’ve honed the concept enough.
To start teams off with a concept like this, you have to separate the core from the periphery. Separate the things that are absolutely important from the things that were just “ the idea we had for how to do it.”
A single UI decision can cause a week of unnecessary work. A programmer could struggle to refactor a bunch of Javascript only to discover that the detail wasn’t core to the concept. The designer just happened to pick that interaction without knowing the cost.
In practice, this means giving the teams power to redefine scope. Some things are essential and other things aren’t. The team must be able to know the difference and make calls accordingly. To reinforce this, we give teams low fidelity hand-drawn sketches when a cycle starts and spend more time on motivation than the specifics of design and implementation.
Uphill strategies
Teams that track “velocity” and “story points” treat development as if it’s linear labor. Software development is not like moving a pile of stones.
If work was like that, you could count the stones, count the time to move one, do the math and be done.
Work that requires problem solving is more like a hill. There’s an uphill phase where you figure out what you’re doing. Then when you get to the top you can see down the other side and what it’ll take to finish.
The uphill phase is full of false steps and circles and dead ends. It’s where you encounter the unexpected. The programmer says “yeah that’ll take two days” but then they start touching the code and the reality is more complex. Or the designer says “this interaction will be perfect” and they test it on the device and it’s not what they hoped.
The most important question for a team isn’t “what is left?” but “what is unknown?” Can you see the edges? Have you gone in there and seen everything that needs to change? The only way to gain certainty is to roll up your sleeves and engage with the reality of problem.
At Basecamp our teams seek out the areas with the scariest unknowns and work on them first. This uphill work requires strategies. We wrote about these in Getting Real. Open the code, spike something that works, load it with real data and try it. When the whole feature is too big to prototype, factor out the most important pieces and spike them.
The uphill work is where you learn what’s hard and what’s possible and make value judgements. Here’s where you make decisions about those mutable requirements because you’re seeing the real costs and opportunities in the implementation. Learning uphill requires the focus and time given to the teams by deliberately allocated resources.
We’ve done this informally for years, focusing on unknowns and chipping at them first. We recently started formalizing this with the Hill Chart. A question we often ask these days is “where is that on the hill?”
Here’s a snapshot from the Search in Place project that shipped in October.
And here are some moments in time from the To-Do Groups project.
It takes a whole business to ship
Whether teams work in cycles or not is just one part of the story. An “agile” team isn’t going to get very far if management doesn’t protect their time. And if they don’t have flexibility to change requirements as they learn, late nights and late delivery are guaranteed.
Designers and developers can learn the uphill strategies from Getting Real to gain certainty instead of crossing their fingers. Whoever sets requirements can give teams the room to push back in the uphill phase. And resource allocators can take more responsibility to guard the focus of their teams.
We’ve been doing it for 15 years. Hopefully sharing some of these techniques will help you do it too.
UPDATE:
We’ve written an entire book on this topic! You can read it online here: Shape Up: Stop Running in Circles and Ship Work That Matters.
This is wonderful. We need more thinking like this.
Agile is pointless without the “why,” the business goals the company is trying to accomplish and how the work we’re about to do connects to do those goals.
When you approach work this way, the specifics don’t matter. There are many ways to hit the goal, and what we do as a team is try to figure out the best path to that goal.
I have thought and worked this way for a long time. It’s nice to see it explained in such a well thought out manner.