Klaus Breyer

Independent CTO – Technical Leadership, Code & Engineering Orgs.


Not everybody on our team was happy with the overhead of Scrum. But it isn’t easy to change a development process for an (otherwise) stable team.

We tried nonetheless and approached it as an experiment: Test and prove that something new is working for us while not wholly abandoning what is currently working.

As a result, we realized that Scrum and Shape Up are not mutually exclusive but complement each other perfectly. 

Problem Space

But let’s start with the root cause: In the current world of software engineering, Scrum comes with much bureaucratic overhead, while all the effort often results in half-assed features (distributed across multiple sprints). Agile became doing half of Scrum poorly and using Jira. Also, product teams introduced mini-waterfalls to optimize resources while lacking team spirit and drowning in context switches

But on the other hand, Scrum seems to be the best-established method to tame non-technical managers of larger organizations not to interfere too much (at least for two weeks). 

Traditional (but businesswise often neglected) engineering wisdom says: There are two very different types of speed: short-term speed (Sprint) and long-term speed (Marathon). In software development (and in running as well), you can’t have both. (Actually, to get both, Intervals are a possibility.)

Another solution to deal with this Dilemma is splitting the team altogether. Then, a product has a “Feature Team” and a “Quick Reaction Force” to ensure stable operations.

Solution Space

Okay, but what is Shape Up? If you have never heard of it: In some sense, it is timeboxed method for feature development, while it is agile in the original intent. Nobody can explain it as well as Ryan Singer himself. If you have not already, watch this video before continuing with this article.

So, Reasons for Shape Up are plenty. But furthermost, the implications for engineers and designers are that they interdisciplinary work together on the same thing, rather than preparing different non-working parts that do not fit together. While for business, it is all about getting more deliberate in how you allocate resources to create value for users.

Our Experiment: Augmenting a stable Scrum process with a Shape Up track to have the benefits of Shape Up without making a frightening “all-in” decision to ditch Scrum. 

Before we get into more details, first, a bit of context: I am currently the Tech Lead of a remote international team to develop a PWA product in the IIoT context.

Scrum working mode: 

  • 4 Software Engineers (fulltime)
  • 2 UX (parttime)
  • 2 UI designers (parttime) 
  • 1 PO (with other responsibilities as well)
  • Working together for well above a year in this exact constellation.
  • PO decides the focus of the next couple of sprints.
  • UX and UI work with PO outside Scrum, preparing everything for the developers.

It is not precisely dual-track Scrum, but a formal method was not necessary: We have excellent communication between the trades, and things are ready when the engineers need them.

Still, there was always more pre-work than Engineering could implement cleanly. And that always came with pressure in every engineer’s mind. 

Also, in planning, tickets with medium priority were pushed to the next sprint, again and again.

We used the vacation season, when almost half of the team was gone, to try out Shape up. We hoped that a very stripped-down team could work with high efficiency and without the Scrum ceremonies. 

Our Shape Up working mode:

  • The project to work on was defined in advance by the PO.
  • Strong collaboration between developers and designers and PO during the shaping phase
  • The timeframe was specified upfront. In this case: 8 weeks. 
  • Fix team, no vacations during this time 
    • 2 Engineers (fulltime),
    • 1 UX Designer (parttime)
    • 1 UI Designer (parttime)
  • No external testers. Testing is part of the team’s interdisciplinary responsibility.
  • There are no meetings for this team except to show an intermediate status at the joint Scrum review.
  • Shape Up team organizes itself: Dailies and progress tracking is in their hands. 
  • Cooldown phase of 4 weeks (2 sprints) afterward to strengthen inter-engineer collaboration while UX + PO leads the shaping of the next feature.

While I am writing this article during the shaping phase for the second Shape Up sprint, for me, some first general patterns start to emerge:

  • Product Owner: There is an extensive phase of collaboration between the PO and the whole team during the shaping, led by UX. In return, almost no obligations during the implementation because no formalities require a PO presence, like sessions for refinement, planning, or estimations.
  • User Experience: A UX designer was part of the Shape Up team for ongoing product decisions. In practice, this designer kept a lot of the meta picture in mind and owned the test cases. 
  • User Interface: The user interface was led to some part by engineering, by what’s possible. So designers needed to make some compromises, which they otherwise would not have allowed. But all in all, I think they spend significantly less time on the project.
  • Engineering: Engineers loved the meeting-free time to tackle some challenging problems of a very technical feature. Besides the coding, it is worth mentioning that they came up with many of the final product’s bells and whistles. Also, they were more involved in testing the feature directly with the beta customers. 
  • Business: Knows precisely how much (time) budget they want to allocate to tackle a specific problem.
  • Collaboration: An amount of time to get work done that almost felt unreal. To work when there are fewer meetings, more synchronous communication, and everyone involved is working on the same topic. 

An exciting aspect emerged for the rest of the team (working within a regular Scrum track): Communication for them was also much more efficient when there were no longer 4 developers but only 2 developers who had to coordinate. (Remember: communication increases exponentially.)

Our Learnings:

  • Designers should (as developers) also not be shared across Shape Up and Scrum when possible. 
  • If we want to continue this work style, we see Kanban as a better fit for the baseline work than Scrum.
  • Collaborative shaping workshops are better in the real world (note remote)!
  • Shape Up sprints can vary in length depending on the feature and other circumstances.
  • When the scrum team is stretched thin, it is crucial not to create additional pressure on them with too many new features when they are already busy onboarding customers and fixing bugs. 

Things that we have not implemented from Shape Up:

  • We didn’t have multiple pitches competing (yet)
  • Therefore, no betting. 
  • We didn’t use Hill charts for progress but integrated the Shape up Team into our Scrum reviews.

This particular team’s next step is to decide its future process. But not by a rash decision to throw Scrum entirely overboard. First, the other engineers and designers need to gather some experience with Shape up. Only then a well-informed decision for the future process is possible for the whole team.

So, if you (as the reader) will only take away one thing: You can have both. You can try something out without sacrificing something that works.

If there are any questions, inspirations, or other thoughts: feel free to contact me via email. I am happy to chat about this topic and Shape Up in general – because this brings an exciting new aspect to my 12-year-long journey: teams working happy, focused, and collaboratively on problems that are worth it. 

Whats next?

So, was this all? No, not quite. 

This blog article is the first of a whole series I plan to write on how Shape Up can work for existing scrum teams. Feel free to give me feedback on what to write about next. I was thinking about:

  • What projects Shape Up is not suitable for
  • Learnings of a tech lead to fully participate in a Shape Up
  • How the Shape Up team structured the work for themself
  • The challenge to PO and UX designers is that things are not “overshaped” before Shaping up.
  • The role of UI designers and how to cope with the brutal transformation of their position. (outside the ivory tower)
  • Challenges to codebase and developer communication when building a significant feature parallel with an ongoing Scrum.
  • Business thinking in terms of “investments” when using Shape Up to drive product decisions. 
  • Solutions for particular challenges in the face of agencies.

Leave a Reply

Your email address will not be published.