Has anyone experienced Basecamp’s Shape Up?
Basecamp published an online book describing its product development approach, called Shape Up.
I particularly liked how it treated design/prototyping, communication, and reducing scope.
Once we release Budibase we might adopt Shape-up. It would be great to hear your opinions on the subject.
You can access the book here
No, but I would love to :)
We switched from a kanban-scrum-thing to Shape Up right after the book came out. I can say two things: 1) it's had a noticeable, calming, focusing effect on our entire company, and 2) it's been pretty rough, with some moments of almost giving it up.
For context, we're a small company with only 12 people but it's $4.5M in annual revenue. We only have 4 developers, but our marketing team has gotten a little on the Shape Up train as well. With a company this small, the methodologies and tactics of one team tends to spill into the other teams whether you like it or not.
The way we switched to it went something like this. I shaped a bunch of work during a 2 week sprint. At the end of the sprint, we went into our first cool-down. During that time, our developers had only two tasks: first, they needed to read a good portion of Shape Up, and second they could work on any tech debt or learning they wanted to work on.
During that period, I held the first betting table with my boss -- our CEO. She was open to the concept, though basically at the time she thought, "Ok, another developer thing. As long as you're still maintain the same output, cool. You do you." She's cool.
So she bet on the only work I pitched. It wasn't very much like Ryan writes in the book. But it was a start. We kicked off our first build cycle. It was only 4 weeks, but since we were used to 2 week sprints those 4 weeks really felt like a luxuriously long time. We built and shipped a feature that I shaped on purpose... it was a long-awaited feature our CEO had been dropping hints about for over a year. I thought that it might be the perfect thing to show off this new methodology.
And it worked! At the end, with the feature live, we went into cool-down and I pitched another round of projects to our CEO at the betting table. This time, I had enough time to shape that we had 4-5 shaped projects for her to choose from. She started to see the value in this: that she finally had the control to choose pretty big dev projects immediately before we build them, which gave her the power to respond to realtime priorities as they change. She liked that.
And now we're kicking off our fourth build cycle tomorrow. I don't see us switching away from Shape Up any time soon.
Hey Kiley0. First of all, thank you for taking the time to write your comment. I have a couple of questions:
Sprint times - I thought they were 6 weeks with a 2-week cool-down period. How come yours were 4?
Shaping - how do you compile the different bets?
Tools - what tool do you use to manage the process?
Moral - do your team like Shape-Up?
Productivity - Is your team more productive?
Once again, thank you for your comment. It's great and I've shared it with my team.
Joe
Happy to share! We started with 4-week build cycles just as a way to ease into it. Jumping from having done 2-week sprints for years to suddenly a 6-week build cycle felt a bit too jarring. But now, with our fourth build cycle, we're on to 6-week build cycles with 2-week cooldowns.
For shaping, I have a single Dropbox Paper doc where I capture every idea that someone mentions. No idea is too small or too big. They all go in there. Then, based on business priorities and what our theme is for the quarter, I pick one or two of those ideas and start to shape them. I usually open up Whimsical and write a sentence or two about the problem, a paragraph or two describing the solution, and a wireframe or two if necessary. Then when it comes time for the betting table, I take those assets and put them onto a one-pager for me to print out and put in front of our CEO. I place 4-5 of these one-pager pitches in front of her and we talk through each one. Then she picks the ones she wants us to build in the build cycle and that's that!
During the build cycle, we use a combination of a Dropbox Paper doc that describes the different projects in the build cycle and Trello. In Trello, we've track what Ryan calls "scopes" in the book. Each list in Trello roughly equates to a scope. It's not perfect though, sometimes the projects are more like a bundle of tasks that are all related instead of a nice & neat little scope. It's ok, we don't sweat it too much.
For morale, I do a retrospective at the end of each cool-down (right before we kick off a build cycle). I have asked our team if they like this process better than our former kanban-scrum-thing and they unanimously said yes, they like this better. They like having the space to build the solution in the right way, which may sometimes include some refactoring and discovered tasks that would never have made it into a backlog in the old way. Our company likes it as well, they all know when we're in cool down and when we're in build cycle.
One thing we've had to adapt is when to address bugs. We couldn't quite pull of just "letting a bug be" as Ryan writes in the book. So we have invented "Bug Fix Fridays" in which we pause the build cycle work and just tackle any bugs or small issues that have popped up throughout the week. It allows us to still be responsive when a customer finds a bug or our team needs some new marketing page added or something, while still keeping 4 days of the week to focus only on the build cycle tasks. It's a compromise, and it's working.
Are we more productive? I think that answer has nuances. In terms of pure sprint-based points, I think we are pumping out fewer points-per-week. But in terms of delivering fully baked features that are a priority for the business within a short window from when the priority became a priority? We're knocking it out of the park. We've delivered 6-7 of these rather large features in just four build cycles, compared to probably 2-3 of them in the same amount of time when we were doing scrum. So yes, I think we are more productive for things that matter.
Let me know how you like it! And let me know if you end up adapting it at all for your team, we can learn from each other.
Thank you again for taking the time to provide me with such valuable information. I have circulated your response to my team. I am convinced Shape Up is right for us and I'll be sure to let you know how it goes.
Thanks again.
We use some of the principles. I know of another large company that does as well.
That's great. There are few case studies out there. It would be interesting to hear how others are using it.
Thanks for sharing, I loved Getting Real back in the day.
They're amazing. Intercom are also great.