Any stories of Shape Up adoption failures?

1

We’re about to adopt Shape Up on our team. We’re very excited. I’m also seeing some distinct risks.

I’m curious if there are any stories from folks who have tried and failed to implement Shape Up or failed to get great results with it? What went wrong? Any post mortem lessons for us?

Thanks!

2 Likes
2

I’m working on something (sadly a blog post). I’d be happy to talk at your convenience :blush:

2 Likes
3

We are about to embark on Shapeup … no pressure :slight_smile: hopefully your blog post is out soon enough for us to read it - and watch out for any pitfalls or areas of concerns.

4

While we wait to hear from folks on the problems they’ve encountered, could you share the distinct risks you’re seeing as you look at adopting Shape Up?

5

Sure! These are not insurmountable risks, and a few folks in this forum have pointed out mitigations to these. I’m just curious if anything became a reason to revert to a past process or move on to another one.

  • Requires high trust in the Builders (designers & engineers) at every level of the organization, including stakeholders
  • This is a new mental model for many designers & engineers. How many get stuck in past ways of thinking?
  • If Shapers are totally hands-off, is execution impacted?
  • Were the larger cycles too much of a risk for the business?
3 Likes
6

Our team is still using Shape Up (2nd full cycle underway), but a few kinks we noticed in our previous cycle (that we are working to address in this one) include:

  • Lack of team input on the appetite. Some team members felt the appetite was unrealistic and did not feel empowered to push back. We’re now doing project orientations before the start of a cycle to mitigate this.
  • Unclear review process for product/design. We have defined a process for the next cycle.
  • Too much/little detail in the pitch. This is something we feel will naturally improve over time.
  • Cool-downs being used to finish projects. This is a problem with the team or the appetite, and something we also feel will naturally get better as we understand our team’s capabilities.
  • Lack of easily-reviewable information about project decisions. Aka there is no final spec and it can be cumbersome to wade through a project to understand what the final deliverable looks like because it can vary from the pitch. We haven’t figured out a good solution for this yet!
3 Likes
7

Not having high trust in people (either because you can’t give it or because someone doesn’t deserve it) is a more fundamental problem that can’t really be solved with process so I don’t think it’s a reason to avoid or discount shape up. If anything, Shape Up would give individuals a chance to grow in those areas that require giving/getting high trust.

I’ve distinctly seen two buckets when initially implementing, those that try to adapt Shape Up into past ways of thinking and those that adopt their own approach to fit with Shape Up. I honestly think the people who actually read Shape Up cover to cover are the ones who can shed the past more easily. It becomes easier once you get a few cycles with successful hill charts, scopes, etc. and can use them as examples for others.

If previous processes requires the people now called “Shapers” to be fully engaged in execution, and now they’re completely hands off, yes it will be impacted if others depended on them. We haven’t found any way around product managers being completely hands off during the cycle. It doesn’t really seem practical and it also doesn’t really seem to be a fundamental principle of Shape Up. I might be biased though because I don’t want to be completely hands off :smiley: but I’m also not being pushy or just checking status, actually solving problems with the team is where I want to get involved. Shapers also have to be involved when it comes to making trade offs unless they’re crystal clear about must haves and nice to haves which is never the case.

We don’t find larger cycles being too much risk, what we find more often is that we need to weave small batch projects between larger batch so that we can focus on either customer-specific requirements or small refinements that we consider to be blocking larger progress. I think this will smooth out over time and we’ll do more big batch cycles than small with some mind set changes - for example, if something is working but engineering thinks it needs to be refactored, then make sure that’s being taken into account when de-risking a project that touches that part of the code base, so they can leave it better than they found it, rather than dedicating a project to black-box changes.

3 Likes
8

We have just ended our 3rd cycle, sharing some observations, learnings, and tips.

  • Not getting the level of abstraction right: Many of our pitches go too close to the implementation detail or are just theories. If you start to see implementation details in your solution, take a step back and read more on this. I’d recommend this video, where Ryan discussed where this idea came from. It is important to get the abstraction right.

  • Not enough research or pushing the research downstream: Sometimes, the shapers don’t put enough time to research the problem or the solution. This results in the research work being pushed downstream and delaying the projects. Thumb-rule: (Most) Research is for Shapers.

  • Rushing the shaping: We found that shapers were rushing to write pitches too late. This will almost always result in bad pitches, especially if they’re too hands-on during the cycle. Shapers shape during the cycle, while builders build.

  • Grab bags: Often, shapers are inclined to group multiple small-batch projects into an umbrella term of “improvement” or other such vague terms. Keep an eye out for these and split them into ad-hoc tasks or small-batch projects (depending on nature and size). A weak and vague problem statement is a good indicator of such a project. Bullet lists are another.

  • Carrying in the notion of working in silos: If your team worked in silos, it has to change. Building demands collaboration. Assist them in leaving the old way of working behind. It will only help them grow in their career, regardless of which process they use.

  • Just reading the book: Shape Up is different in many ways and will require a mindset change in the whole team. Just reading the book is not enough. Understanding the principles behind is equally, if not more, important. If you’re the one evangelizing the process, you’ll have an additional responsibility to educate the team on this topic :smiley: A responsibility I personally enjoyed.

I hope this helps you equip better for your journey. :rocket:

Cheers!

4 Likes
9

Coming back to this question to reflect more. Some of this will echo what @nayaab said and that we’ve observed/are guilty of as well

Writing pitches last minute, Implementing too fast

This seems to be the biggest one. It was particularly noticeable in our first cycle when we decided last minute to implement shape up. If you’re going to do shape up I recommend giving a full 4-6 weeks to shape and prepare the team for what’s coming. You also want to make sure that the people doing the shaping have ample time out-of-cycle and start early. This seems to be a side effect of Shapers being very very heavily involved in in-cycle work to be able to focus on Shaping, and the main problem that doesn’t seem to have an answer in sight for us yet.

No betting table

While I think generally not having a betting table is okay, I think it can lead to situations where work isn’t shaped well enough, and projects are started with incomplete shaping. There needs to be a checks and balances system for a group to agree “that is properly shaped and we’re willing to bet on it”.

Late Cycle Scope Creep

This is the one that I’ve seen a LOT, which is that the team working on the project is left to their own devices for too long during initial cycles (not enough Shape Up experience) and I end up seeing things implemented that were clearly defined as out of scope or a rabbit hole. Part of this is building habits, making sure we’re going back to the initial pitch often, having discussions early, and doing the hard work first (get everything up the hill first).

No Breadboards and Fat Marker Sketches

I don’t have any causal data on this one but it seems to me like the projects that don’t include breadboards and fat marker sketches are the ones most likely to get into the weeds.

Smells
Some of the little things I’ve noticed that need to be addressed to change the mind set.

  • Up to date to do lists and hill charts - I’m all about leaving everyone alone to do their work but I don’t think it’s too much of an ask for engineers and designers to keep detailed lists of what is remaining to be done. My feeling is that if they’re keeping track of these lists somewhere they might as well be visible, and if they’re not then there’s a problem that is deeper than being able to Shape Up.
  • Radio silence - OK if hill charts and to do lists are changing, not OK if nothing seems to be happening. Check in to see what’s going on. A lot of time it’s habit building, the work is being done but not transparently. Make sure the team knows that the benefit of the transparency is that check-ins are not longer required. Trust but verify
  • Conviction - I struggle with this one myself, which is to not have periods of time where you’ve created a project of “refinements” that “need to be done” and calling it “small batch”. That’s laziness and not Shape Up. I should go shut down my refinements project oops.
1 Like