How to release features on-time, every-time
A common mistake in the business world is to build a business without getting early feedback from customers.
This problem also exists in the development sphere; developers go for too long without getting feedback from other team members and product owners.
At DNSimple, we’ve been exploring ways to avoid this. Lately, we’ve been following the Shape Up method. It pushes you to confront the “unknowns” head-on. This feels counter-intuitive, but it works because it gets all the chips on the table early-on. Here’s what it looks like.
1. Collect the scopes
At the outset of a project, we need to identify the “scopes” that make up the project. We do this by picturing the project as a circle and divide it into all the chunks that need to be done. In other words, “if we completed all of these things, would the project’s requirements be fulfilled?”
Now that everything is all out on the table, let’s start to bring some order to the project.
2. Order the work
At the outset of a project, we have big plans and grand visions. It’s very tempting to get rolling on that stuff – these are the “knowns”. They are shinier. Exciting. More interesting. But… this leads to rabbit holes and unfinished projects.
It’s painful, but without exploring the unknowns, we can’t know how big the project is. The real next step is to sort the scopes by how “unknown” they are.
A hill chart is the best tool for understanding this. At the beginning of the project, our focus is on getting all the scopes to the top of the hill as quickly and thoroughly as possible. We call this phase “working on the unknowns” or “figuring things out”.
Once again – our first objective is to move all the “scopes” to the mid-line. The unknowns come in a couple forms:
- We have no idea how to complete the task.
- We know how to complete the task, but haven’t done it in-context.
Moving things up the hill usually does not result in production-ready code. Time is spent doing research and creating things to throw away (we call them spikes). Time is not negotiable in Shape Up, so we only continue to work on something until the “unknownness” fades. Then, we move on to the next most “unknown”. We find ourselves working from “unknowness to unknowness.”
Once we feel all the “unknowns” are gone, we start making things happen.
3. Build the scopes
This is the good part. Getting. Stuff. Done.
We keep the Shapers in the loop while we’re building. This is best done through quick demos or screenshots. For an added incentive, these demos are given when the code hits production (but typically under a feature flag).
From Day 1, things begin to be uncovered. When this happens, we add them to our “Uncovered” list. It doesn’t matter how big or small or silly they seem at the time. Every couple days, we review these items to see if they need to be dealt with. In many cases, it is the same things bubbling up in different forms.
For smaller items, we bring out the scope hammer, typically in the form of “We’re thinking about removing XYZ because of ABC. What do you think?”
There really seems to be a propensity for big “discoveries” or “paradigm shifts” throughout a project; they’re put there to derail you. Don’t let them. We surface these quickly to all stakeholders so there are no surprises in home stretch. We handle these differently depending on the situation:
- We write down these concerns
- Sometimes, they come up in a later discussion or retrospective
- Sometimes, we can document the issue so someone can pick up the task later.
- Sometimes, we move it to our “cool down” list.
- Sometimes, we’re ready for a mini-crunch-time and just do it. This is generally least desirable, but is a good fit for a well-shaped task like refactoring.
If an item is a “nice to have”, we mark it with a tilde (~) and… forget about it. It feels awful, but this is precisely the sacrifice that is required in order to ship on time.