In Shape Up, we work in 6-week cycles to solve business problems. This constraint is meant to put pressure on the pitch writing process.
With only 6 weeks, we must ensure that we are not biting off more than we can chew, or rather that we know we can chew (and swallow) everything we’ve bitten.
Because it has such a large impact on the success of a cycle, the hardest work in Shape Up is pitch writing. Pitch writing is more than just capturing a list of technical requirements. It’s prioritizing the most important problems to solve. It’s defining a scoped project that can be completed in a single cycle. It’s creating alignment on the business objective a cycle team is delivering towards.
Accomplishing those goals is not easy, and we’ve experienced this first-hand. In this post we will share some techniques that help to prevent churn and reduce failure. You can use these techniques to refine a pitch and complete an entire project in 6 weeks.
Kitchen safety
Ideally, a project should have little need for redirection when a team is working on it. Incomplete pitches cause churn and put the success of the project at risk. Although this is true in all agile processes, in Shape Up, it is paramount to prevent churn during a development cycle. In fact, the punishment for an incomplete pitch is non-delivery of the solution, rather than an extended deadline.
Despite the very real risk in defining an incomplete pitch, balance is still important, and over-prescription has a negative impact as well. Overly-prescribed technical solutions limit the ownership a team feels and break Shape Up’s trust model.
At the worst, losing ownership of the solution shuts off the creative problem solving within the cycle team. A cycle team needs to feel empowered to make decisions about the solution. They may be aware of better, cheaper, or faster solutions.
Over time, if developers are not engaging their creative problem solving skills, the capabilities of the team will atrophy and morale will suffer.
Menu planning
A well planned menu understands and adapts to varying cooking times or takes advantage of similar ingredients across multiple dishes. A well defined pitch should do the same. Just like different ingredients require different preparations, types of uncertainty in a pitch will affect how you define and implement a solution.
Here are the types of uncertainty that we’ve seen affect the completeness of a pitch, and ultimately the project’s success. All these things need to be taken into account and will affect how you shape a pitch.
- A solution depends on another team, or teams - The effort involved in collaboration or coordination is highly uncertain and can jeopardize the 6-week deadline.
- Design and user experience work - A design that is too high fidelity is like food photography: it might look good, but can it actually be cooked and eaten? The people responsible for how it looks must be a part of the team, and able to respond to changing technical needs.
- Limited understanding of complexity - Almost anything is possible with software, but not everything is practical. Any technical solution within a pitch is going to be constrained by time, resources, and other technical and non-technical concerns.
- Assumptions - Qualifying statements like “should” are indications that you’ve made an assumption. Assumptions indicate risk. Real work needs to be done to eliminate assumptions whether it’s before or during a cycle.
- Invisible non-functional requirements - It’s dangerous to assume certain things (e.g. deployment and observability) are included in the feature work. This time needs to be understood and accounted for when sizing a pitch.
Quality ingredients
When developers are given a pitch, they should be expected to solve the outlined problem, not determine whether it is even possible to solve. There’s a bit of process you can follow to identify and reduce uncertainty in a pitch and give developers something more actionable. Although it can be tempting to think a pitch is simple or obvious, without careful review, unseen details can derail an entire cycle.
We want to be confident that all of the ingredients are fresh and can be combined to produce an amazing dish. Here are some techniques we’ve used to help product owners deliver better pitches.
Highlight known assumptions
It’s not always clear whether the writer of a pitch knows something to be fact, or is making an assumption. The goal is to understand how much risk is involved in the solution. Comb through the pitch and just simply mark everything that you don’t know for sure is a fact. We’ve all been bitten by assumptions like “the foundations of this work was done last month”, or “there’s a sweet JavaScript library that does pretty much what we need”.
Confirm your assumptions
Having assumptions isn’t inherently bad, but not identifying them will lead to wasted effort even in the best-case scenario. Just the simple act of marking things as assumptions will clarify how much uncertainty we have. Even if we aren’t able to eliminate all of our assumptions, when made explicit, it’s easy for a cycle team to prioritize research. The assumption is no longer hiding invisible effort or possible changes to scope, and the more you can do to eliminate assumptions, the more effective a cycle team will be.
Make your priorities clear
The team needs to know how to prioritize the work within a pitch, so they don’t work on a low-value, but easy component of the pitch first. Listing priorities is good, and will help the cycle team work in the right order, but it’s not all. Clearly defining the motivation behind your priorities aligns the team with them and allows the team to solve a problem, not just implement a solution. Shared understanding empowers a cycle team to make the best decisions for the business, make the right trade-offs, and build the right things.
Portion control
The goal of the pitch is not to fill 6 weeks with work. It is to shape a problem in a way that it can be solved in 6 weeks.
Account for empty calories
6 weeks goes by quickly, and not every moment will be pure additive feature development. There will be research, exploration, and collaboration that takes time and is easy to leave unaccounted for. There will be activities that are usually left as invisible work when estimating. Things like reducing the number of assumptions remaining in a pitch and elevating the level of confidence a team has about changing a code base. Make a point to understand and include these activities when sizing a pitch.
Leave room for dessert
Cycle teams, as well, need to leave room to button up the functionality at the end of the cycle. Demos, docs, and debugging are all part of feature work that often are pushed past deadlines. However, a solution isn’t truly delivered until they are complete. If you’re not sure what’s done because you’re buttoning things up during cool-down, then it’s hard to capture what was learned during one cycle and plan for the next.
Put your napkin in your lap
While it can be tempting to dive right in, we’ve found that taking a more strategic approach as a cycle team can have a large impact on the success and happiness of the cycle. Shape Up, itself, emphasizes shipping during the first week, compounding the temptation to push off risk and reach for what’s immediately available to work on. You may find that delivering a short spike will produce more value in your first week than picking low-hanging fruit. Attack the assumptions and the risk first and produce a confident plan as your initial priority.
Conclusion
An organization that works better together is more successful, and this post highlights ways to use Shape Up and pitches to facilitate communication between different parts of the business. Successfully completing a project is like sharing a family meal, and the best restaurants don’t just offer a menu, they create an experience. At Test Double we care deeply about improving the way teams work together. If you’d like to learn more about how we work with teams, say hi.
