Products go through two phases: forming and building.
In the forming phase, ideas start small and delicate. They then get interrogated and prodded. They combine with other ideas. These ideas grow and take shape. It’s not a straight, predictable line of growth. It’s more chaotic. One question can crumple an idea into nothing. Whilst another, can bring the idea springing back into shape. At each part of this process, ideas grow and complicate. Ideas seldom get introduced into the world as simple as they started. They almost always are too big and you need to refine them.
This happens in the building phase too. There are millions of opportunities to get lost in the details. Even a trivial task of adding a button becomes a chance to play-around with the copy and tweak how it looks. This is a problem for some tasks more than others. But each task presents a temptation to complicate.
“Work complicates to fill the available time.” — Parkinson’s Law
What compounds this issue, when it comes to delivery, is being too confident in the plan. We leave little time to handle unexpected tasks. We treat software like building an IKEA bookcase. We think we have all the parts worked out and we just need to fit them together.
In software development most of the time we’re not operating under the normal rules we’re used to. Code is structured and rigid. But, when systems of code come together things become more complex. With complexity comes unpredictability. With unpredictability, you’re better-off leaving your plans or instruction manual behind.
Instead, we make changes and observe the impact. Our understanding grows as we build. We uncover new requirements and tasks which we hadn’t even considered. Because they weren’t planned, you won’t have enough time to handle them.
In real life, issues are discovered by getting involved in the problem. That means to-do lists actually grow as the team makes progress. — Ryan Singer, Shape Up
So we have a problem, we form ideas which start simple and grow complicated. We take these complicated ideas and plan to build them. We underestimate the complexity and don’t plan for the unknowns which come-up. This is what causes projects to take much longer than expected. We get used to this being normal. We rinse and repeat.
What can we do about it?
When we are forming ideas, boundaries help stop ideas becoming too complicated. They change the framing of the problem. This simple technique makes sure that you are solving at the right scale.
For example, let’s say that you run a book business and want to solve a customer pain-point. Many customers are requesting to receive a monthly invoice for their purchases. You start thinking about how to solve this. You’ll need to create accounts for these customers. You’ll need to track transactions and introduce a reconciliation process. You’ll need something for support agents to manage them. In a matter of minutes, your ideas around this have grown into a multi-month project.
Ask yourself: If we only had 2 weeks, what can we do to solve this problem?
In asking this question, the framing changes. The scale is now many times smaller than before. And it forces you to consider what the core of the problem is and to focus on that. It creates a more productive discussion.
In Shape Up Ryan Singer defines this as the appetite, a wonderful term for this:
Appetite is the amount of time we want to spend on a project.
So, in the formation phase, boundaries help define the shape and the structure of ideas.
When building, we want to make sure we are directing our attention effectively. We want to avoid spending time on the superfluous. These are the button tweaks in our earlier example. We want to make sure we focus on core functionality.
Giving the project a timebox and defining how much attention it deserves helps. It forces us to make decisions and trade-offs. In doing this, the team prioritizes each decision in the context of the project as a whole. It makes you ask: “Is spending an hour tweaking the design the most important thing to be doing right now?”
The trade-offs are the classic ones between quality, scope, and time. It’s hard to ship when you can always make improvements. But this only works if the team has the flexibility to adjust the scope. This is the “fixed time, variable scope” principle. This works at different scales:
-
At the project level: “we want to be able to charge by invoicing in 3 weeks”.
-
Workflow-level: “User can set up a payment account. 1 week”.
-
Task-level: “Code a form for creating an account. 1 day. ”
Without boundaries it is easy for ideas to grow too large and tasks to balloon. Defining clear boundaries helps keep this in check. It changes the framing of problems in the beginning. It forces us to focus on what is core in more of the decisions made as a team. Use it when discussing ideas and when building. It will encourage focus on what is core and will improve the chance that you deliver your project on-time.