Hey, at Avocode, we use Shape Up methodology to manage our product and deliver updates faster and in better quality. Errhh, hold on, what's Shape Up? Good question! In this blogpost, I, Josef Kettner, the Product Manager at Avocode, would like to walk you through what Shape Up means and give you 👉🏽 the tools and practices we used to implement it in our 30+ member team!
How we worked
Before we start, let's jump back to 2019 real quick.
At that time, we realized that we had a couple of weak links in our process, which looked something like this:
Here are the problems we had:
- Know when to stop: We didn't have any mechanics to stop the development of the features. In reality, it meant that we developed everything till the very end, which often took 2x longer than we originally planned. But, hey, at least it's out, right...
- Focus on your priorities: Our developers were out of focus. Often, another team would send a request for some ad-hoc task, which meant that instead of focusing on the ongoing project during the week, devs had only about 2.5 days of uninterrupted development time.
- Feature creep is real: It often happened that ideas came after something was already in the final stages of development. So we decided to add it to the scope anyways. Yet, we quickly found it was the most expensive form of iteration.
- You can't delegate what you don't know: Yeah, the tasks, feature descriptions.. let's be honest. There were serious holes in them. We didn't spend enough time to think things through because we were always busy with something else, and the devs needed to do something.
You probably didn't encounter any of these, right? 😛
Back in those days, we tried to use the so-called Scrum-like workflow (coz agile was cool, so everyone was doing agile, and we were too). The truth is it wasn't Scrum at all. We took some parts from Scrum and adjusted them to our needs. But as our team grew and updates became more complex, the workflow somehow stopped working. So we tried to tweak it a bit:
- Pair programming
- More meetings and discussions
- Yelling, arguing, crying... (at home in the shower)
Guess what, it didn't work. It made me feel that we should consider a complete switch rather than keep patching and tweaking the existing workflow.
Around that time, one of my devs sent me Shape Up book written by Basecamp's Ryan Singer. Coincidentally, I had plans to take a short vacation. So here I was, in the back of my car looking after my kid and reading the book.
My first impression of it was - this sounds like the answer to all of our problems. Yet, I was a bit hesitant because every management book makes the same promise.
But there was something else about this one. I liked Basecamp's take on work and life, in general. So I decided to run it by my direct manager and one of the co-founders of Avocode, who got equally excited about it. In fact, we believed in the concept so much that within a month, we managed to fully implement Shape Up at Avocode.
So what is Shape Up?
With respect, I'll borrow this from Tom Hombergs
The key takeaways are well summarized in his book review
How to implement Shape Up?
Follow this guide to find out how you too can easily implement Shape Up in your team.
We started by documenting the method according to its main parts - Shaping, Betting, Design & Development, and Cool-down - to make sure everyone at Avocode can quickly get on board with it.
Luckily, all the documentation is available for you in the template. And I get that every company is different, but I promise, it's a great place to start and change things as you see fit.
- 🔄 Shape Up lifecycle - template
- 🙇 To Shape - template
- 💎 Shaping - template
- 💰 Betting table - template
- 👨🎨 Design - template
- 👨💻 Development - template
- ⛄ Cool-down - template
2. Shaping & dev cycles
The second part of our preparation journey was to set up the process, i.e., create one source of truth for tracking shaping and development cycles.
We start every new cycle by creating a Pitch for every idea we picked at the To Shape meeting.
For this, we've developed two different Pitch template with several checkboxes, i.e., things you don't want to forget about while writing your pitch.
You don't have to check all of them every time, but here is a couple we find most valuable to us:
- Expectations from stakeholders: It helps shapers align their thinking with the stakeholders and avoid misunderstandings at the betting table.
- Onboarding: Onboarding is crucial if you want your users to adopt the features you release. So we have a dedicated person who comes up with a plan for it.
- Consultation with devs: Our process is inclusive. Before assigning tasks to our dev team, we consult with them on the implementation mechanics.
After the checklist comes the central part of the pitch, which pretty much reflects the structure from the book:
- Identifying the Problem
- Shaping the Solution
- Identifying the Rabbit holes
- Watch out for No-gos
- Outlining the Release plan
After we finish shaping and betting on the new ideas, we pass them on to the development cycle table, set due dates, and assign team leads and members. At this stage, we try to reduce overhead and make our devs their own managers as much as possible.
3. Company-wide implementation
All in all, it took us about a month to get everything ready (and we're happy to save you time with our 👉🏽 template). Now we had to assign shapers and introduce the process to the whole company. Initially, we thought that all team leads could double as shapers. But we quickly realized that 1. good shaping takes time and 2. some people are better equipped to deal with particular issues. Eventually, we decided to involve a group of people best qualified for the job, i.e., our VP of Product, Product manager, CPO, and CTO.
What we did right from the very beginning was the way we introduced the team to Shape Up. We held two separate workshops: one for everyone in the company and the other for the devs, each with a particular focus/goal in mind.
What we learned from the first Shape Up cycle?
The first cycle was the beginning of a new era at Avocode. Here is what we learned from it:
- The Shaping: Shaping can be a full-time job. We were too ambitious about how many projects we can deliver. But, we learned how to prioritize!
- Betting table: Make sure to prepare for the meeting. Get familiar with the pitches beforehand, invite the shapers, establish a way to assign capacities efficiently, and do check your devs' vacation plans in advance.
- Development: You need to work with your devs and help them grow, make decisions as you go when things are missing in the pitch, and extend some projects into the cool-down if necessary. Don't expect everyone to get used to the flow from day one and become a team lead, but the ability to fully focus on the project at hand delivers great results.
- Cool-down: To give your devs some real cool-down time and avoid burnout, allocate at least one developer outside of Shape Up to work on smaller tasks. And do run retrospectives to identify problems and adjust your flow for the next time.
All in all, since we implemented Shape Up, we had no regrets! I hope this guide and our template can help your workflow as well. Let me know on Twitter. Cheers.
- Shape Up template by Avocode
- Original Shape Up book
- Shape Up community forum
- Shape Up meetup community
- Rework podcast from the authors of the Shape Up
- Shape Up book review by Tom Hombergs
P.S. If you are unsure about what we actually do at Avocode, we help teams build great digital products. We have the best Inspect tool on the market. You can work with Figma, Sketch, Adobe XD, PSD, and Illustrator files to quickly export assets in multiple resolutions and formats, generate and copy code in 10+ languages, get the text from your designs in two clicks, keep track and download design versions, leave contextual comments on top of the designs, and, of course, share, store, organize, collaborate, you name it. Check it out. We have a free trial.
What is Avocode?
It’s an all-in-one tool for teams that want to code and collaborate on UI design files 2x faster.