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.

The Problem

Three things were getting increasingly difficult:

1. Knowing how much work we could get done in a given time span. This made it challenging to plan for the future and to be transparent with our customers when they asked about our roadmap.
2. More customers meant more “chores,” or “business as usual” (BAU) tasks were piling up. It was unclear how to prioritise them.
3. “Nice to have” tasks were left at the sidelines, never important enough to prioritise. Things like code refactoring, tweaks to internal tools, small bug fixes in the UI, etc.
   

None of these are great situations to be in on their own, and combined they were becoming a real problem.

The Idea

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.

Customer-focused iterations

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.

Do-what-you-want iterations

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.

Does it work?

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:

1. Each customer-focused iteration that passes gives us a better idea of what we’re capable of. We’re not perfect at estimating, but we aren’t far off either. We’ve also been able to give more certainty to our customers about features that are not far away, which has been a huge relief for our customer-facing colleagues.
2. Leaving some slack in each iteration to address BAU has worked well, and we’re on top of the incoming tickets. Some of the work that has happened in do-what-you-want time has been to automate BAU work, and we believe this is working as intended.
3. In the 2 do-what-you-want iterations so far we’ve been able to prioritise big pieces of refactoring work that were difficult to balance before. We didn’t feel guilty for working on it, and the rest of the company knew to expect it and that we would be back on customer-focused work soon.
   

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.

Where do we go from here?

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.