As CV Partner has grown to serve more customers and double-digit numbers of staff, some cracks started to show in our “just get on with stuff that’s important” approach to working.
This post will focus on how the tech team at CV Partner plans and executes on its work.
Three things were getting increasingly difficult:
None of these are great situations to be in on their own, and combined they were becoming a real problem.
What we’re trying is an adaptation of how Basecamp works. We alternate between 6-weeks of customer-focused work and 2-weeks of what we’re calling “do what you want” work.
At the start of each customer-focused iteration, we all get together and decide on the highest priority pieces of work. To help with this, we keep track of feedback from users in productboard. If we pick something from productboard to work on, we move it to a ticket in Clubhouse in the “prioritised work” column. Clubhouse is our source of truth for all pieces of work.
Then we estimate how long we think each ticket will take. We don’t want to get bogged down in estimation, so the shortest time estimate for any single ticket is 1 week. It’s better to have slack than to feel rushed. Having slack gives us flexibility if (when) something unexpected comes up.
The amount of work we allow for each iteration is the number of people multiplied by the number of weeks, minus a few weeks to make space for BAU work. Over time, we review our estimates to figure out if we’re estimating well. With every iteration that passes, we get closer to perfectly accurate estimates (right? right?!).
Then we get to work.
At the end of the 6-weeks we have a retrospective, for which we use Retrium. We like to use the 4 Ls: liked, learned, lacked and longed for. We spend 10 minutes coming up with things over the last 6 weeks that fit in to each L. For example, if we didn’t estimate well, it comes up in the learned column. If we did estimate well, it comes up in the liked column. We spend the rest of the session talking about common themes, and coming up with action items to address them in the next iteration.
These are much more freeform. Bug in one of our internal tools that screwing up your workflow? This is the time to fix it. Technical debt starting to grind you down? Pay some of it back. Got a cool idea that will make our lives easier? Have at it.
There’s no planning meeting to kick off these iterations, and that’s on purpose. This time is meant for you to do the things that will make you happier and more productive.
Of course, we still have to stay on top of BAU in these iterations. Ideally BAU won’t take up more than, say, 10% of any iteration. If it does, it becomes a company priority to automate it.
We aren’t certain yet. We’ve done 2 customer-focused iterations, and 2 do-what-you-want iterations. The early feeling is that we like this way of working, and see no reason to stop doing it.
Here’s how it addresses each point from the beginning of the article:
The fixed-length nature of each iteration means we have to think about how long things take. If it looks like a ticket will take longer than an iteration, we break it down into smaller chunks. We believe this to be better than letting work run on indefinitely. Having regular checkpoints in a large piece of work is good for morale, and helps us avoid big-bang releases.
There are still some rough edges. For example, we’re not brilliant at keeping Clubhouse clean. We have a lot of tickets sitting in the “inbox” column, where work is kept before it has been prioritised. This distracts us from the work that we’ve collectively decided to prioritise.
We also know that we’re going to have to do some extra work to scale this process as we grow. It will become counterproductive to have the whole company involved in planning, and we’ll have to split into multiple planning sessions. We have ideas for how we will do this, but that’s a topic for another post.