From Scrum to Shipping Work that Matters with Shape Ups
From Scrum to Shipping Work that Matters with Shape Ups
How Klausapp grew its product to thousands of happy users.
This is a guest post by Mart Objartel. He is a Senior Product Manager at Zendesk QA, ex Klausapp. In this article Mart covers what Shape Up framework is, and how they applied it at Zendesk QA, ex Klausapp. Note that it is more of a reflection of a past, rather than the current state, considering that Zendesk acquired Klausapp recently. So, the acquisition can be a sign that the product team at Klaus was doing something right.
Thank you, Mart, for sharing the knowledge. And thank you, reader, for visiting Tallinn Product Group.
What is Shape Up?
Shape Up is a framework for running product development teams by collaboration and productivity company Basecamp. Shape-Ups focus heavily on execution and shipping features or products.
In very simplified terms, Shape-Uping divides into three parts: Shaping, Betting and Building. During Shaping a small team, a product manager, tech lead, UX-designer, and other essential stakeholders usually shape the project. The focus is on outlining the rough scope and asking, "How much is this idea worth? (Shape-Up, page 15)". The result of Shaping is a Shapeup pitch that is a project one-pager. Betting is just another term for prioritization or selecting what to work on if there are multiple shaped projects. Building is what it sounds like, developing what has been shaped. There are many more details to it, but that's the essence of it.
Shape-Ups are eight-week cycles. There are two weeks of shaping, six weeks of building, and then two weeks of a cool-down period for the engineering team to work on whatever they want, try out something new, innovate. While engineering is in the cool-down another shape up is being prepared. There can be multiple smaller projects inside the six weeks, or if there is something bigger, the project can span multiple Shape Ups. The six weeks of build time also isn't rigid, and there are special cases when it's OK to extend the project a few weeks. The focus is on shipping, not sticking to some abstract artificial rules.
Shape Up VS Scrum
It's easier to start by what product management artefacts and ceremonies Shape Ups don't have:
There are no detailed requirements or specs. The startup pitch is at the right level of abstraction, and the team has the autonomy to decide how to solve the problem.
There's no planning or refinement ceremonies, no story points or other task estimations. The team creates their own tasks and decides what needs to be built.
No sprints.
No product backlog (more about that later).
In the Scrum framework, a very large amount of effort goes into improving the predictability of team output or, in Scrum terms, having predictable velocity and capacity. A lot of time is invested into Sprint planning and then Product Backlog Refinement. The team tries to forecast the effort in literal person-hours or story points (a measure of complexity) and then analyze all the tasks in detail to refine the effort estimation and understand what needs to be done (dependencies, affected systems, etc.). In the scrum, the team success is often measured by how reliable are they continuously predicting the velocity and capacity.
In the Shape Ups, the focus is on shipping. This means that the discussion is around how much are you willing to bet on solving a certain problem, new feature or product. Once there is a decision that the problem is worth solving and you have decided how many weeks of engineering resources you are willing to commit for the bet the team just starts working. There is no shapeup sprint planning because there are no sprints in classical terms. The team is responsible for creating all the tasks necessary to solve the problem described in the Shape Up pitch as they see fit. Instead of detailed refinement of all the issues, the team starts working and figuring out what to do. There is no product backlog created by PM/PO or other stakeholders, this means that once the Shape Up is done and shipped, all the issues that did not make it into the launch are deleted or archived. The assumption is that only the most important work gets done and waste is cut from the scope. If the trimmed issues are important they will pop up again in future Shape Ups.
There's lots of risk and unknowns at first but at some point, the team gets over the hill of the unknown by working on the problem not by refining and planning before starting the work.
At the peak of the hill of work, the team can more or less confidently forecast if they are able to get it done within the agreed time, if they need an additional week or two or whether they should stop instead. The success of the team is measured by getting stuff done.
In my mind, the biggest difference between Scrum and Shape Up-s has not been in the absence of sprints or difference in cycle lengths. In scrum, the emphasis is on the process of developing and optimizing that process. Timeboxed, equal-sized bites of predictable effort are the goal. In the Shape Up-s, the emphasis is on solving a problem and shipping, even if it takes a week or two longer than expected.
There is no more anxiety during planning to forecast if all the necessary user stories or tasks fit into the sprint that is needed to launch. The engineering team can focus on shipping and there is no need to try to prioritize bugs, new features and eliminating technical debt in the same very narrow pipeline. Nobody can add stuff to the sprint because there are no sprints and the team itself is responsible for creating tasks to deliver the pitch.
If there is suddenly a need to do something different from what was agreed in the Shape Up pitch, then you stop the cycle and shape a new one. It's normal that sometimes such things happen. In the scrum, you would try to fit new issues into an existing sprint and kick something else out.
What do you need to be successful with Shape Ups?
Ideally, you want to have multiple Shape Up cycles running in parallel (Lanes) and these Shape Up cycles are shifted so that there would be always someone cooling down and available to work on critical issues. Simple math tells that you need a minimum of 4 parallel cycles (lanes) to ensure that you have always someone available for unplanned work. If you are unable to create at least four lanes, there will be some gaps (weeks) when all engineers are assigned to shape up projects and you need to pull them off to deal with fires.
You need mature teams with product engineers. There are no assigning tasks by product owner/analyst or refining the work. The team is trusted with a project and "they will have full autonomy and use their judgement to execute the pitch as best as they can." You can't expect this from teams who are used to just doing assigned tasks based on detailed spec. The team must also understand the product, problem and customer. I'd imagine it would be next to impossible to implement this framework in any setup where the engineering team is outsourced.
Running Shape Ups has to be a management decision. Betting on a project means that the teams are committed to working on their projects and nothing else during the six weeks. This means saying a lot of NO's even to fixing bugs. If you start making comprises there, the goal of shipping will have an impact. This also means that it would be very hard to successfully pilot Shape Upping with just some teams while the rest of the organization does something completely different.
The Shape Up team must be self-sufficient and able to execute the pitch without the help of outside resources. If the project needs changes across different parts of the product, there shouldn't be systems owned and maintained only by some specific teams. This is a recipe for dependency bottlenecks and prioritization hell.
What do we do differently at Klaus?
Product development frameworks are always more akin to guidelines than exact rule books. While some follow the frameworks to the letter, I think they are missing the point. A product manager should not care much about any framework. It is important that the development method works for the whole team and fits into the organizational culture and needs. In Klaus, it currently seems to be Shape Up inspired way of working.
Shape Up book does not talk about validating your bets, testing or working on UX. So this is what we have had to add to the process. For more complex problems, the whole UX-design enchilada can take more time so the work starts in some cases a few weeks before actual Shaping.
This also means that (at least at the moment) we don't have many competing Bets and pitches and when we start Shaping we are already quite confident that this is the right problem to tackle.
Shape Up book puts a lot of emphasis on the right level of abstraction for the input that engineering teams start to work on (Shape Up pitch). Ideally, the level should be 'fat marker sketch".
It's really hard to UX-test complex interactions with fat marker sketches and I can't see that there would be time to UX-test different solutions later, while the team is already in the build cycle.
When the Shaped Up project changes how different parts of the product interact with each other and these interactions are complex, then it's really difficult to find the right level of abstraction without going into the detail in the pitch. Sometimes our pitches are already quite specific on the solution because the work on the problem happened during research and UX testing.
Conclusion
Scrum, SAFe and other frameworks have their place but it seems, that many successful product companies are moving on [1,2,3,4]. Scrum is a good starting point to build up trust and knowledge but once you have mastered scrum, try advancing to the next level. Don't let some made-up rules hinder what really matters. It does not matter whether it's Mission teams and tribes, autonomous teams or Shape Ups. A shift in mindset is required. Important is to keep the focus on the outcome, not output and keep improving on getting things done.
 | A guest post by
|