Shape Up Forum

Experience Reports: Before and After Shape Up

I posted a survey on Twitter asking Shape Up adopters to tell about their before-and-after experience. Here are some of the responses.

Feel free to respond to this post with your own experience.

Mike at SynchroNet:

We’re actually SHIPPING real features and the team seems more energized. The devs are coming to product team with questions and helping us do a better job of shaping.

Omid at Stem:

Before is a classic “everything is all over the place” scenario. After is that we are actually shipping things in the intended amount of time and people know what to do.

Jason at Healthcare Bluebook

We’re a team of analysts, so our product development is usually more “process” development, relying more on pure code and less on UI/UX. Before reading Shape Up, our methods of prioritizing work were inconsistent, dealt with an endless backlog of requests, and frequently encountered scope creep which forced us to stretch projects out much longer than anticipated. We’re still in the early phase of implementing some of your methods, and the results look very promising. Everyone seems to have better clarity on what’s important, the determination to scope projects accordingly, and the tools needed to provide concise yet informative status updates to the larger team.

Matt at Automattic:

I already see my team thinking deeper about the problems they’re solving. By owning scope within the pitch they are making early tradeoff decisions and focusing on delivering value rather than blindly implementing a product requirement.

I’ve heard sentiments on my team like “Shape Up is changing the way I think about speed and building products.”

Hill Charts in particular struck a chord as a new way of understanding progress as unknowns-vs-knowns.

John at Addition:

Productivity is through the roof. It’s infinitely easier to produce good work on time with a clearly shaped pitch upfront and a generous deadline of 6 weeks (sounds obvious but it’s easily overlooked!).

Prior to Shape Up we’d let things run as long as required. More than once we ended up canning work that had been in the go for months.

Since moving to the Shape Up approach we’ve completed two cycles and hit our targets each time. I think that’s largely down to recognising that as a product development team, time is our currency. Learning how to ‘spend’ that currency effectively has changed things in a big way for us.

Everything is more focussed and, quite frankly, enjoyable.

Paul at Pathwright:

It’s much easier to unstick a known need and get it to the starting line (we used to have to create detailed wireframes to do this) and also more flexible and fun for the designers and devs. It’s been a very nice upgrade all around. (thank you!)

Filip at Lime Technologies:

More focus and purpose. We actively make a bet and stick with it for a pre determined timeframe. Before we didn’t really have a sense of direction or purpose and often jumped between things, or they draged on without any clear end

Simone from Meltwater:

Before:

  • 2 weeks sprints
  • Quarterly objectives
  • many meaningless ceremonies (including grooming, syncs with PO etc)
  • lack of continuity in work, every two weeks there was an opportunity to derail the current work to some other direction
  • feeling of guilt when working on tech debt or tech improvements rather than “objectives work”
  • lack of sync between Engineers and Product Owners (required extra meeting)
  • difficult to discuss and decide OKRs
  • unhappy Engineers, unhappy PO

After:

  • 6 weeks iterations
  • clearly defined goals for the iteration, no detailed plan (no need for pre creation of stories and grooming)
  • each pod (2-3 engineers) works on one objective and generates stories as needed
  • PO creates stories for product work (customer discovery, evangelisation, etc)
  • morning standups sync different pods and PO on the current progress - PO discuss her progress just like any other engineer (by-directional sync, eng and PO have a chance to participate and feedback on the current tasks)
  • No chance to derail the current objectives
  • More focus, reduced meetings (no longer need for many syncs as we are in sync every single morning, no grooming, we discuss progress and next steps each morning - we keep each other in check, no scope creep)
  • Tech improvements, learning, experimentation is done in the 2 weeks cool down and we feel good about it - no pressure to work on objectives because there is no objectives to work on in that period.
  • Upcoming objectives for next iteration are built in cooperation between engineers and PO during the current 6 week iteration, there is no conflict and no need to “sync”, we are always all on the same page, decisions are easy
  • We presented very ambitious objectives for last iteration that were questioned as “too much” but we nailed all of them plus aspirational objectives 4 days before the end of the iteration.
  • happy excited engineers
  • happy excited PO
  • we are now a much more united team, there is no boundary between product and engineering

David at store2be:

Programmers are reportedly more motivated. As a PM, I am not nearly as much involved inside the cycles as I was when we were doing sprints. Back then, I totally felt like a delivery manager and had no time at all to think deeply about what to do next. Now, when a cycle is ongoing, I easily get to use 80-90% of my time to fogure out the right thing to tackle next (ehatever that might be in the current context of the business).

Henning at NewStore

One thing that made me happy as a designer is to see that engineers adopt to the breadboarding.

We did a discovery session with the team to brainstorm about different solutions and everybody was into it. After a couple of weeks, they discovered some unknowns and told me we need to breadboard – wow, that never happened before!

The shaping part resonates well inside the product team with the different product owners because we now have specific terms that we can use to define the work that needs to be done upfront – Is it shaped or not? Where are we on the hill? Do we still have uncertainties? Can this be shipped in 6 weeks? Is there a version that can be done in 2 weeks? What are the rabbit holes?

Brian at Pingboard:

We work on much more meaningful projects, because it needs to be worthy of investing 6w. And, the projects ship on time. Before, the next work was what was next in the queue, but not necessarily the most valuable work. The short cycles meant we spent too much time trying to estimate the work, then more time on why something wasn’t shipping “on time”.

The teams are trusted and empowered, rather than micromanaged. We have more collaboration and people are more invested in the problems we choose to solve and how we solve them.

Dan at Hatch Loyalty:

Before Shape Up, our team operated like a fairly traditional scrum team. We used Trello, worked in 2 week sprints,held daily stand-ups, sprint retrospectives, and of course, we managed a gigantic backlog of never ending tasks. Typical scrum shenanigans. This worked OK enough in the early days of our companies existence, but as the product and team matured, we started experiencing some pain points. More specifically:

  • Our backlog was getting larger and harder to understand—leading to unnecessary stress and anxiety.
  • Our estimates would frequently increase in scope halfway through the sprint and we’d have to carry work over to the next cycle, which is a sign that we were moving too fast and not properly understanding the full scope of a feature before committing to it. This naturally lead to more bugs, technical debt, etc.
  • It was getting hard to understand the value of certain features, why they were worth doing, etc. Which ultimately made everyone feel like they were working in a “feature factory.”
  • Finally, and perhaps most importantly, there was a general feeling that we, as a product and engineering team, were NOT doing our best work. And that feeling sucks.

It was at this time that I started trying to research our way out of the current process. Shape up did not exist at that point—at least not in it’s current form. To be honest, it was these two articles that ultimately convinced me to move our team over to Basecamp.

Since the Shape Up book didn’t exist yet, our team tried our best to piece together a process based on those two posts. It also helped that you (Ryan) graciously offered up some time to answer a bunch of process related questions I had about working the “Basecamp Way.” By the time Shape Up came out, we were already about a year into a process that closely resembled what was in the book, so that was just icing on the cake. It helped firm up our understanding of each concept. Also, having the book gave us more language to use when talking about those concepts, which was super helpful.

It’s now been about 1.5 years since we started “Shaping Up” and I honestly can’t imagine working any other way. There have definitely been some growing pains and learning curves along the way, but I can say with confidence that our team is happier, calmer, and more productive. We’re doing our best work. If there are teams out there struggling to ship features or producing high quality work that you’re proud of, then I strongly recommend reading this book. It won’t disappoint.

Jeremy at Retail Zipline:

Our team loves the clarity and focus of shifting to the longer, more articulated cycles.

The biggest impact though has probably been on the rest of the organization. Our marketing, customer success, and account management groups have far more clarity on what’s coming so that they can communicate with our customers effectively.

Prior to the 6 week cycles, we worked in traditional 2 week sprints. This can be useful for consumer products where change management isn’t common, but when you have enterprise customers one of the biggest issues is getting them comfortable with frequent change. Our externally facing teams were struggling with letting customers know what was coming with notice when we didn’t know what would be built less more than 2 weeks out.

Now, with 6 weeks of notice, not only are we building and releasing more complete features but we’re also able to generate more excitement from our customers and help them get comfortable with all of the improvements.

Drew at Differential:

The misnomer with two-week sprints is they aren’t actually two weeks. You have 10 days. Take out time to test, to QA, to ship, and to plan the next sprint, and you’re looking at about 7 days of real work. No real, valuable, needle-moving product work can be done in that time. So we had continual, rolling feature work that never seemed to end. And it was all based on unrealistic, half-baked estimates.

Now we’re shaping features, handing over the responsibility of projects to the team, and then giving them the time and focus to ship the feature. And we’re having better conversations with our client partners because shaping is a great place to talk strategy and alignment around business objectives, jobs-to-be-done, etc. It’s a forcing-mechanism for asking the right questions, but also settling on a real solution to bet on.

Phil at Close.com

Before we started thinking in 6 week cycles, it was more common for us to take on larger projects that had a tendency to drag on for months rather than weeks. Now, it’s much more common for us to ship something meaningful in 6 weeks and show faster progress to customers.

The 6 week timeframe feels like the right size to do something fairly substantial but small enough to force you to really prioritize, having a “break” in between big focused projects, and giving the entire company a clear plan for what’s being worked on. The idea of “fixed timeline flexible scope” has been very helpful toward ruthless prioritization. There are always ways to keep working on something for longer!

Shape Up has given us further clarification around many of the ideas from the 2016 blog post and perhaps most importantly – given us more shared vocabulary.

We’ve been having conversations about Shaping, Appetite, Scope Hammering, etc. and these ideas have helped us better shape work.

Having time for Cool Down has been very helpful for personal sanity, giving time to breath, and having a regular schedule for ongoing technical debt improvements, bug fixes, and other generally less-structured work.

Aylon at Actionstep:

Before: Always felt like I was behind things and desperately trying to catch-up. Devs needed work (tasks) from me quicker than I could prepare it. Never had time to think about things because I had to spend so much time writing user stories & detailed acceptance criteria. And even still, I usually had low confidence about what I prepared; how clear the tasks are and how good/valuable the solution I’m getting the team to make. Also spent a lot of time project managing instead of product managing. A lot of time in meetings

After: I finally feel ahead of things and much more confident about the work I give to the team; the understanding of the problem and validity of the solution. I have more time to think deeply about things, do research, and think strategically as well. Writing a pitch (we call them recipes) is much better than writing up all the user stories. Besides taking significantly less time to put together, I also find them clearer. The devs have really liked getting recipes and find it clearly helps them understand the full picture of what they’re doing, not just the tasks. Less meetings. I’m calmer. It’s also given us better language to use internally, so we’re having better/faster discussions.

John Henry at User Interviews:

It has made planning so, so much easier. Despite knowing that we shouldn’t – we had been slipping into a bad cycle along these lines.

  1. Agree on something we thought was important
  2. Leadership asks how long it would take - we say something like 5 weeks
  3. Leadership follows up with “can you do it in 4 weeks?”
  4. Then we’d mock the idea to a much higher fidelity to increase our confidence about doing it in 4 weeks.
  5. The team is giving a very specific idea to work on with an aggressive timeline.
  6. Bad things start to happen.

So fixed time has broken that cycle for us. Now everything we discuss has the same cost – 4 weeks (in our case). And we don’t commit to exact solutions or features. It is abstracted a bit “we can make this type of progress in this problem space” and the team has a lot more room for creativity and autonomy on what they deliver. It has been great.

6 Likes

We’re experimenting with build cycles and cool down periods and it has been going well. The cool down period has given us some much needed breathing room and time to handle unplanned work. It has also helped stay focused during build cycles.

@rjs thanks for creating this forum.

Thanks for creating this forum, @rjs!

If you all are interested in a more in-depth experience report, I’ve just published a case study of how we’ve implemented (parts of) Shape Up at store2be: https://signsofastruggle.net/2020/01/11/implementing-shape-up-a-case-study/

I’ve always felt like the “purity” of Shape Up in Basecamp’s implementation can seem intimidating if you’re stuck with a barely working Scrumban process. The goal of this case study was to give others a glimpse at the messy reality of a small team trying to change things for the better.

Let me know if this is helpful – and/or better posted in a different context.

6 Likes

Great writeup @David, thanks for sharing!

1 Like

Great feedback.

At Scolab we started the adoption of ShapeUp about 6 months ago and we are midway into our 3rd cycle.

Our main motivation was that despite having a good Scrum adoption after 40ish sprints on the “dev” side, the “product” side of the company was no able to get into the same mindset and it was causing major imbalance even up to the higher management, where we had a lot of “fog of war”. For me, the “betting table” was a very smart way to put back the spotlight on the need for timely and “involved” decisions on what to build.

One major change we made from the vanilla ShapeUp described in the book, was that we allowed everyone in the company (50ish employees) to shape pitches and did not restrict the time allowed or try to control what they would pitch. In return, people mobilized, put forward a lot of ideas and we found hidden talents.

On the “build” side, people didn’t “freak out” too much when we declared “scrum” to be “dead” and that we needed to move on quickly. We kept the original 3 teams but gave them more autonomy and focussed on the proper tranfer of “power and responsabilities” when validating pitches.

To do a quick turn-around in just a few months with involed a few consultants for training and change management, and the overall transition had only the typical adoption outliers which got resolved along the way.

Deployments of news features in production has been maintained and overall trust and satisfaction seem pretty high. After 25 years in software development, I can say this is the most interesting (and human) flow I’ve seen up to now.

We’re still doing a lot of improvement and adaptations from the original concept, and we’re planning on doing a more formal evaluation after our 5th cycle.

Cheers!

1 Like

What other modifications?

Among the main changes from the book:

  • While we dont have a “backlog” for pitchs, we do track who is working on which pitch and try to coordinate people to get enough involvment and feedback. This is necessary, since everyone can start a pitch.
  • While members of the production team will be assigned/paired and autonomous during cycles, they still belong to one of the three core teams for the 3 main segments of our product. They decided to keep scrum rituals for team cohesion such as dailies and Retrospective meetings. Most of them don’t like to work alone on a deliverable.
  • The “go live” at the end is often not “fully in users hands”. Up to now, most deliveries have been behind “Feature flags” and will be released after more validation work is done. Our client base are schools and teachers… they don’t crave “new” stuff on a monthly basis.
  • We use our tracking apparatus even for discretionnary pitches. Meaning that we invite people to write pitches and track them the same way, even if the work won’t be vetted by the betting table (either because it’s not a large enough investment or it might not even be development)
  • The whole notion of “giving and receiving feedback” during the shaping process has been difficult. We are now working on making this part more formal and transparent to make sure that when a pitch gets to the betting table that we have a little more meat on the bone co
    ming from each competencies.
  • We still find the need to write Use Cases and/or Job Stories during the building phase, otherwise the QA team has a hard time building the proper test suites. Narrative plain-language pitch documents are not a good enough input for QA.

Would love to hear more about second to last bullet.

1 Like

Yea second to last bullet is super important if you’re going to open up pitches to everyone and they actually get involved. I feel like we’re “technically” open about this but nobody but the people who actually bet on pitches have actually written them or really strongly influenced what they are. Would love to hear more about that as well.

Haha Joining the bandwagon for wanting more details for the second to last bullet point. Curious to understand what’s been difficult about giving/receiving feedback, and when is it difficult? I.e what are the circumstances around that struggle? Thanks :slight_smile:

1 Like

Yes… the “F” word… Feedback.

Some of the most repeated frustrations have surrounded feedback. Feedback is notoriously hard in business, since it’s a moment where people have to “commit” to something or pass judgement on someone else’s work.

The common issues have been:

  • I wrote and published a pitch, but nobody gave me feedback.
  • Someone wrote a pitch, but never came to me for feedback.
  • I’m a director… a pitch was published, then accepted the week after, but I didn’t get to give my own approval.
  • I gave feedback, but it’s not in the pitch!!!
  • I gave a feasibility estimate but something else was written down.
  • I asked for feedback, got feedback, but this person broke my pitch.
  • My pitch was turn down at the end, but I did not get enough explanations.
  • On the betting table, a pitch is published, but we have nooo clue whether feedback was gathered from others.
  • And more.

So, among the good practices we currently have in place:

  • Golden rule: all key documents are transparent and available to all: the list of all pitches, the actual pitch documents, the approval process, the betting tables decisions and the resulting work affectations.
  • We have a kanban flow, managed by a “guide”, to track every pitch right at their initiation and know who’s shaping what. The guide has no say in evaluating pitches (no judgement) until they get to the betting table, he only helps to “keep track”, give reminders, connect the right people to the right resources and gives pointers on how to properly fill the agreed pitch template.
  • The current flow has the following states: Candidate, Suspended, Shaping. Written, Published, Refused, Abandonned, Accepted.
  • We have a central “low noise” channel where the guide will post the newly published pitches and remind everyone of “where we stand” on the cycle and publishing deadlines.
  • We actually had consultant come in and give training on “giving and receiving feedback” for the management team. When givin feedback, managers can easily skewer ongoing work without realizing it.
  • The pitch template asks to credit the list of contributors (and specify their contributions) and the list of consulted people. This is VERY important to know how serious the team as a whole is about the pitch and allows us to go ask more targetted questions ahead of the betting table.
  • The pitch template also asks for “Required expertise” for the actual delivery, which helps us get some final feedback from the right experts ahead of the betting table.
  • The finale feedback when the betting table either accepts or turns down pitches has been shortened and we instead focus on giving richer feedback “face to face” if needed.
  • The investment table gives feedback “as a unit” and now as individuals. (this prevents mixed messages and the perceptions of good guys and bad guys)

As for the next set of changes we have planned:

  • We will have a separate kanband (in Jira) board to try a formal track of “opinions”.
  • The board will initially track: Appetite check, Feasability, and generic opinion.
  • Shapers can use this to formulate a requests for other to get involved and the “guide” will then be able to help to mobilize the right people.
  • The list of relevant opinion request will appear at the botton of each pitch (using a wiki embeds).
  • If needed, an opinion can be handed out to a list of specific people as a “contribution task”.

That last part is important to manage expectations and prevent the “Ships Passing In the Night” effect:

  • People have busy schedules and don’t have time to read everytihing
  • People don’t see all the requests/notifications
  • People have a hard time “keeping track” of their todos
  • People don’t want to be “annoying”
  • People avoid things that are complicated or scary (like giving negative feedback)
  • People just plain forget

So, our guess is that once a need for feedback has been expressed. The “guide” can then help to followup with people and make sure that a pitch that is stuck will eventually get enough contributions, or highlight some missing contributions… much like a scrummaster would track and solve impediments.

At the moment, as the head of development I’m doing the “guide” role, but we are designing this role to be eventually delegated to anyone with good coordination and communication skills.

2 Likes