There should be proper allocation of time and money in order to build a feature that protects the team so that they can focus on their assigned tasks. Too much distraction won't make the designers and developers make progress.Only the management can protect the cycle of three (1 designer, 2 programmers) of which is rotated based on need.

Deliberate resource allocation

Give the teams the power to redefine scope because they are able to differentiate what is essential and which aren't.

A Mutable Requirement

Software development is not like moving a pile of stones from point A to point B.Challenges come often and to be able to solve them is like going through an uphill phase where you try to figure out where you're going and then when you get to the top, you'll be able to see the other side and what it takes to finish.Curiosity is an important regimen for a team because the only way to gain certainty is to engage with the reality of the problem.

Uphill strategies

An agile team will not go very far if management does not protect their time. The team should have flexibility, especially the management because as the team learns, late nights and late deliveries are guaranteed.

It takes a whole business to ship

<figure><img alt="" src="https://miro.medium.com/max/500/1*3YYxCEncxps74aaDGyxHh" width="680" height="341"></figure>Agile started off as <a href="http://agilemanifesto.org/" rel="noopener" dir="ltr">a set of values</a>. 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. <a href="https://m.signalvnoise.com/how-we-set-up-our-work-cbce3d3d9cae" rel="noopener" dir="ltr">We work in cycles</a> at Basecamp. But in addition to cycles you need three other practices to ship on time and in good health.<h1 data-selectable-paragraph="">Deliberate resource allocation</h1>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.<h1 data-selectable-paragraph="">Mutable requirements</h1>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.<figure><img alt="" src="https://miro.medium.com/max/500/1*No8qYDENp0B5HFsxigKqDA.png" width="680" height="482"><figcaption class="kb kc da cy cz kd ke av b fs bz fi" data-selectable-paragraph="" dir="ltr">One of Jason’s sketches for the team that built <a href="https://m.signalvnoise.com/new-in-basecamp-3-to-do-groups-6e19efc65fcc" class="cd im" rel="noopener" dir="ltr">To-Do Groups</a>. They ended up choosing not to build the “add” buttons below each group.</figcaption></figure><h1 data-selectable-paragraph="">Uphill strategies</h1>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.<figure><img alt="" src="https://miro.medium.com/max/500/1*aTJOF6uQ-jlNuCbCj4BQCg.png" width="680" height="253"></figure>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.<figure><img alt="" src="https://miro.medium.com/max/500/1*xV-g3zRDo6Zuu0QfTBGtNQ.png" width="680" height="324"></figure>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 <a href="https://basecamp.com/books/getting-real" rel="noopener" dir="ltr">Getting Real</a>. 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.<figure><img alt="" src="https://miro.medium.com/max/500/1*76MTQ9YjkjjitvoYxf_xxw.png" width="676" height="346"><figcaption dir="auto">Different phases of the uphill and downhill work</figcaption></figure>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 <a href="https://m.signalvnoise.com/new-search-and-more-in-basecamp-3-2a34020be96" rel="noopener" dir="ltr">Search in Place</a> project that shipped in October.<figure><img alt="" src="https://miro.medium.com/max/500/1*jHg80qqmuUy--y_s1zRO5Q.png" width="680" height="370"><figcaption dir="auto">First reworking search results, then moving them into the nav</figcaption></figure>And here are some moments in time from the <a href="https://m.signalvnoise.com/new-in-basecamp-3-to-do-groups-6e19efc65fcc" rel="noopener" dir="ltr">To-Do Groups</a> project.<figure><img alt="" src="https://miro.medium.com/max/500/1*iw-l7ZX4Fy0QGhZhfPd1Vw.png" width="680" height="379"><figcaption dir="auto">The three most important pieces went over the hill first</figcaption></figure><figure><img alt="" src="https://miro.medium.com/max/500/1*cr0Cdil9R7TDJLHzD7dF3w.png" width="680" height="375"><figcaption dir="auto">Wrapping up</figcaption></figure><h1 data-selectable-paragraph="">It takes a whole business to ship</h1>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.<h1 data-selectable-paragraph="">UPDATE:</h1>Since this article was written, we built and released a feature in Basecamp 3 so you can make your own Hill Charts. See all the details here:

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…

problemsolving

Problem Solving

communication

Communication

teamwork

Teamwork

product

Product & Design

leadershipandmanagement

Leadership & Management

Agile started off as <a href="http://agilemanifesto.org/">a set of values </a>. 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.

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. <a href="https://m.signalvnoise.com/how-we-set-up-our-work-cbce3d3d9cae">We work in cycles </a>at Basecamp. But in addition to cycles you need three other practices to ship on time and in good health.

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.

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.

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 <a href="https://basecamp.com/books/getting-real">Getting Real </a>. 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 <a href="https://m.signalvnoise.com/new-search-and-more-in-basecamp-3-2a34020be96">Search in Place </a>project that shipped in October.

And here are some moments in time from the <a href="https://m.signalvnoise.com/new-in-basecamp-3-to-do-groups-6e19efc65fcc">To-Do Groups </a>project.

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.

Since this article was written, we built and released a feature in Basecamp 3 so you can make your own Hill Charts. See all the details here:

Running in Circles

Deliberate resource allocation

A Mutable Requirement

Uphill strategies

It takes a whole business to ship

Christine Smith's ideas are part of this journey:

Related collections

Similar ideas