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.
- Running in Circles - Signal v. Noise
- How we structure our work and teams at Basecamp - Signal v. Noise
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.
- Agree on something we thought was important
- Leadership asks how long it would take - we say something like 5 weeks
- Leadership follows up with “can you do it in 4 weeks?”
- Then we’d mock the idea to a much higher fidelity to increase our confidence about doing it in 4 weeks.
- The team is giving a very specific idea to work on with an aggressive timeline.
- 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.
