Building product at rebank using Shape Up
Like many startups before us, as our team at rebank began to grow we defaulted to a rudimentary form of “Agile” or Scrum to manage product delivery better. Two-week “sprints”, tasks in a Trello board, daily stand-ups, product backlogs and so on. I’d used similar processes working for a couple of other startups prior to founding rebank, and we decided to default to what was most common thinking that was the right way to go for us at this stage of the company.
Why our process wasn’t working for us
Tasks just take as long as they take
We’d decide on some new features or infrastructure to build for the next two weeks, put an effort estimate on it and get to work. However, at the end of the sprint, it was not uncommon for tasks to not be completed as we’d either underestimated the time needed to deliver them or misjudged the magnitude of “unknowns” there were going into the task that resulted in the scope of work expanding. As a result, we were moving slower than we wanted to and didn’t have enough customer-facing progress to get feedback on.
Engineers were too reliant on my decisions
Typical “Agile” focussed workflows would have the CTO (me in this case) or a senior engineer breaking down work into discrete technical tasks and assigning them to engineers. This added a lot of overhead to my role and didn’t empower engineers to use their creativity and technical knowledge to come up with a solution themselves. It makes no sense to hire talented engineers and then assign them work like “code monkeys”, nowhere more so than in a startup.
Not enough time allocated to user feedback and product design
Having a one or two-week sprint cycle in an early-stage startup meant that time we should have been spending speaking to customers and iterating on the product was being consumed by fortnightly sprint planning, requirement clarification, bugs, reviews, retros, backlog maintenance and then sprint planning again. We ended up feeling we were running around in circles. Not talking to customers enough is a really good way to kill your startup early on so we knew this wasn’t sustainable.
After discussing some of these with the team in more detail one of our engineers suggested we check out Shape Up as it seemed to attempt to tackle a lot of the problems we were facing.
What is Shape Up?
Shape Up was created by the founders of Basecamp and is broadly based around three phases of work that happen within a “cycle” — typically 6 weeks in duration:
- Shaping: product owners and designers, with the help of engineers, come together to define a specific problem, propose a solution and decide what the appetite is (we’ll go into this later). The key here is getting the design to the right level of abstraction i.e. concrete enough that the team knows what to do, yet abstract enough that they have room to work out the interesting details themselves.
- Betting: shaped projects of work are brought to the “betting table” where the team decides which projects to work on this cycle. Any projects that don’t get selected are not kept in any structured way (i.e. no backlogs!).
- Building: a team of designers and engineers work on delivering the project, and are given full responsibility for figuring out the tasks and details required to do so. Projects are either completed within the 6-week cycle, or they are killed using a “circuit breaker”— there are no arbitrary extensions on delivery time (or at least very rarely).
The cycle is followed by a two-week “cool-down” where shapers can focus on preparing the next projects to pitch, and builders can work on bug fixes, improvements and even their own ideas for adding functionality and value to the product.
You can read more about Shape Up in detail here: https://basecamp.com/shapeup
Why we like Shape Up at rebank
Two parallel tracks: Shaping and Building
Often when working in agile teams, it can be difficult to find enough time to properly “plan” work as you’re working on a perpetual two-week sprint cycle. Shape Up involves working on shaping and building separately in parallel. So while the builders are working on delivering the projects that were successfully pitched for the cycle, the shapers are speaking to customers and deciding what work to pitch and then bet on for the next cycle.
Assign projects, not tasks
Assigning “tasks” to engineers reduces them to grunts or “code monkeys” and can be horribly demoralising as a consequence.
Instead, the shaping process allocates sufficient time to properly understand and de-risk a body of work — which is then given to engineers to work on uninterrupted for up to six weeks (depending on the “appetite” — we’ll get to this shortly). Engineers use their creativity to find and build a solution and have a complete feature to deploy at the end. High fives all round!
Slice projects vertically, not horizontally
Typically in scrum, tasks are sliced “horizontally” and assigned to engineers depending on the discipline: backend, frontend, database etc. However, this creates a disconnect between the goal of the project and the actual work. Shape Up slices work vertically (by default) into user functionality e.g add user, edit user, delete user which gives the build team distinct, releasable features to work on and maintains a focus on customer impact first and foremost.
Focus on appetite, not effort
The seemingly default behaviour when evaluating a task in a sprint cycle is “how long will this take?” (i.e. effort). Instead, Shape Up focusses on “how much time is this project worth to us and/or our customers?” (i.e. appetite) and is grouped into two “batch” sizes — small batch (1–2 weeks) and big batch (3–6 weeks).
Fixed time, variable scope
In a typical sprint cycle, a task you thought was going to take two weeks but is actually going to take four weeks just gets shifted into the next sprint.
There are a few problems with this:
- You’re diluting the value of your time — the value this task provides is static while the time you spend on it increases.
- Tasks that continue with arbitrary timelines create morale problems for both product teams and the wider company. You need regular wins!
- Having tasks that “just take as long as they take” can erode the sense of urgency in product development which can be fatal for startups.
Having a hard deadline on a project means that you’re forced to focus on the highest impact tasks, hammer the scope accordingly and deliver the project according to the agreed appetite.
No backlogs
Backlogs are terrible for morale as they create a perpetual sense of falling behind even though you’re not, and they can be a time sink to maintain.
“But we’ll forget what we need to work on?!” you say…
Any project that is important enough will keep being brought to the betting table. If you need a backlog to remember it, then it’s not important.
Communicating progress with hill charts
Communicating progress shouldn’t require people constantly asking questions like “where are we up to with x”. It can be very difficult for those outside of the people directly building something to know exactly how far along we are on a project.
Shape Up uses hill charts to communicate progress on a given “scope”. “Every piece of work has two phases. First, there’s the uphill phase of figuring out what our approach is and what we’re going to do. Then once we can see all the work involved there’s the downhill phase of execution.”
If you have any comments or questions on our process then get in touch with me on Twitter or in the comments below.
Thanks for reading
Did you enjoy this article? For more articles like this check our our blog and follow us over on Twitter or LinkedIn ✌️
