All frameworks are wrong, but some are useful: Using Shape Up to improve delivery

There’s been a lot of talk about the end of Agile, set off by the ones who had Agile done to them, but mostly by - in my opinion - bad practitioners of Agile.?

After all, if you boil it down Agile is at its core about getting the right stuff done with the goal to provide valuable stuff to customers (and if you are now tempted to provide your improved definition of Agile, please don’t).

All of the frameworks, best practices, and - frankly - confusing jargon seem to have stumped the much needed idea of Agile dead in its tracks. To be honest, that is why I’ve been hesitant to share my experiences applying Shape Up in improving delivery. The last thing we need now is another silver bullet framework, something new that we can all desperately cling to, expecting wonders. But having worked with Shape Up and applied it to mitigate one of the major weaknesses of Scrum (if you’re wondering what it is: lack of refinement), I think there’s value to be had here, that maybe Shape Up might be the right thing to help you deliver the right stuff.

So just to make myself clear, there is no silver bullet framework, and that includes Shape Up. But, in an adaptation to George Box’ statement: “All frameworks are wrong, but some are useful”.

Shape Up

Shape Up is a framework of practices focusing on improving product development by framing and shaping the right product idea(s), and delivering the selected product idea(s) in a cadence of cycles. In my experience it fixes the need for refinement by the right people at the right time, and pushes on a cadence of delivery by adjusting scope rather than sacrificing time (extending deadlines) or quality. If you’re looking for a complete description of Shape Up, you’d be best served to read the book on it here, or if you are more of a visual learner, feel free to check out Ryan Singer's great Shaping in a nutshell-video.

In this article I’ll focus on introducing three key concepts of Shape Up: Framing, Shaping, and Cycles to highlight the key benefit to Shape Up: refinement.?

Framing

Framing means focusing on identifying the problem(s) and the business value attached to addressing them. One of the issues I’ve seen throughout my years of coaching product delivery teams, is the tendency to apply refinement as pushing out user stories to predefined deliverables (i.e. overcommitted sales promises, or ill-defined “roadmaps”, etc.). Let alone the multitude of business risks taken in those processes, it also grinds the mandate of product people down to ticket monkeys shoveling the next slew of tickets (Hello Jira!) into the furnace of the product team train, just to keep it going.?

In a framing session, the intent is to narrow a problem down, not to fix it or find the right solution to it. I’ve used something as simple as a business case template to support the process, but there are all kinds of pitch templates available if you want them. In my experience connecting the business people to the product people answering the simple question of which customer segment is affected and to which extent, has been invaluable. Also, discussing the time (i.e. investment) the company wants to spend on it really helps to identify early on.?

Shaping?

Shaping is all about finding the options to fix and refining by calling out risks and limitations needed to deliver. Finding the right balance is key here: it is not intended to prescribe the way to build it, it is intended to refine further by sketching options, calling out risks and won’t do’s. Also, the time constraints identified in the Framing phase - how much time do we want to invest into this? - should inform the testing time allowed for testing the viability of options.

The outcome will form a package, ready to be picked up in the next cycle of delivery, if selected. I’ve used the previously mentioned business case template to simply add more context and direction to build the packages. To streamline the selection of the right next thing, the pitches were attuned to the strategic objectives of the company.?

Cycles

Last topic to cover in this article, Shape Up uses timeboxes similar to pretty much any other framework, but suggests longer timeboxes than the typical two week sprints we’ve all become familiar with from Scrum (i.e. 10 working days). A typical cycle takes 6 + 2 weeks: 6 weeks to refine selected pitches into valuable deliverables, and 2 weeks to cool down and start up for the next cycle of 6 + 2.?

At the start of a cycle (in this image “In cycle row”: Build), the product team kicks off by discussing the pitch from the product manager and identifying questions to be worked out, tasks to be done, and clustering activities together. This refinement process is critical to the delivery success, and empowers the product team to own their quality and value delivery.?

Compared to other applications of delivery frameworks (Scrum, Kanban, SAFe, etc.) I have found this process to vastly improve the ownership and cross-collaboration in the product team. The (suggested) timeframe of 6 weeks also allows the team real time to do the much needed refinement work and to deliver something substantial.

In a cycle, the product team is firstly focused on figuring things out. What option works best to deliver/build this? What do we need to know first, before starting to build it? After all, if you’ve had the time to figure out how to build it best, the building it best follows naturally.?

Finally, the cycle of 6 + 2 is not set in stone. I know product teams that have customized their cycles to their needs, allowing a 4 + 1 cycle for instance.

The importance of refinement

I hope you can see that just by applying these three key concepts of Shape Up, the process of refinement is supported throughout resulting in more valuable stuff getting done. More importantly, by allowing the right amount of refinement, by the right people, at the right time, you will make the most out of valuable product delivery time.?

If you’re keen on hearing more on applying Shape Up - the real story including what worked and didn’t work - let me know in the comments or send me a message!