Limit work in progress as a mindset for focus

Limit WIP is a concept from Kanban that is inspired by lean manufacturing principles. It helps to prevent waste and ensure we produce only what’s really necessary for an efficient manner.

This is quite used in manufacturing and software development, but it’s actually a quite useful mindset to help focus, maximize impact and accelerate feedback loops in many other things.

Let’s see some examples of how we can apply Limit WIP to some of our daily work.

On ideas and business experiments

As part of product development, hustle, marketing, and pretty much our daily work, we are constantly looking for new and better ways to achieve our final goals. This is a really good principle we should keep, but can easily put at risk our ability to focus.

Both in personal and company life’s, a good framework has been to think in terms of two phases: exploration and optimization. Exploration is when we are just starting out and don’t actually have an idea where to start. We don’t know what to do, how can we sell it, what should we be selling. In that phase, it makes sense to say yes by default and try many things to hit something that works faster. After having something that works well enough, there’s still lots of things to improve but the pattern should be much narrower to ensure we keep capitalize on the things that work. We need to say no much more and ensure that most of our time is optimizing what works while leaving still some room to experimentation. As a rule of thumb, in an optimization phase, perhaps 50-80% of our time should be spent on the things which worked in the past.

The number of things we are experimenting must also be limited to our ability to execute and evaluate those experiments in the short-term. If we have 10 experiments running for 10 months, the best case scenario is that we will find something that works in 10 months, but if we do 1 experiment a month, we might get that breakthrough right there.

The theme here (following up on all our previous discussions on focus) is that we need to have fewer experiments at the same time so we can be more effective in executing them. This is, however, a big general statement, which everyone will agree on but it’s hard to materialize concretely.

Here is a rough framework, where each team should apply and adjust limits to their phases, capacity, and needs.

Each team should have one single metric to rule them all. This metric should be the best quantitative way to measure if we are on track in the team’s mission. In more complex contexts, it might make sense to have two or three, but more than that will lead to loss of focus, and considering current state I recommend to start by having just one.

Each team every week divides their time between habits and experiments. Habits are the things which have worked in the past, and if we have some of those we should stick to what works most of our time. These should take priority to experiments as they brought us here and are frequently our safety net for progress.

Experiments are well-defined attempts to increase the single metric that works, and there is a hard limit on how many we can have in progress at any instant. Each experiment should be a card on team’s trello, which should have on the title or cover a clear indication of the experiment success status. Each experiment should have clear metrics which will indicate if it works, what are the indicators that we really tried/protocol and a timeout/due date. If after the protocol the metrics are not achieved, we shall mark the experiment as a failure and move to another. If the experiment hits the due date and the protocol wasn’t completed, it means we are doing too many things, and therefore the experiments limit should be reduced by one.

As a way to force rapid iteration, all experiments should timeout in the worst case in two weeks. This might seem harsh, but it’s possible in most cases, and in this framework as we will have fewer things going at the same time we should be able to achieve results faster. It’s true some experiments will require follow-up and waiting on results, but as we have fewer things to do and get on the habit to go all in on experiments, two weeks should be enough if we act on the first two or three days and spend the rest waiting for metrics.

On work and craftsmanship

Naturally doing one thing at a time and doing it well will make much more viable to improve on our craft. When was the last time you saw a craftsmen multi-tasking? We should be weary though in this regard to not go into over-correction and not ship by perfectionism.

Be either processing email, coding a feature or handling a chore, we should strive to touch each task only once, and when we do it do it to the end.

Don’t pick up new stuff (ideas) before finish the old stuff (ideas).

On meetings

Any time we spent talking in sync has a huge cost for the company and our maker schedules. So when on meetings we need to be fully there. The false hope to get ahead on work or kittens will only lead to longer and less effective meetings, so we need to have the habit of put all the screens away during meetings unless they are really necessary for it.

If you feel the meeting isn’t useful enough for you to be fully engaged, just skip it. If you feel the meeting is taking to long and not be productive, participate actively and help drive it into a conclusion.

On focused urgency

There is a culture habit of saying: I’m so busy, I have so many things to do. And in some way having many things to do frequently provides a sense of urgency and productivity boost that is quite welcome.

As we try to work in a more focused fashion, we need to ensure that even if the things we are doing in a given week is small(ish), it was made that way so we could give our very best on each task. Fewer things don’t mean less busy, but instead that we go all in on one thing at a time. We need to get in the habit of saying: I’m so busy, I have this single thing to do, and I need to do it well and fast.

In fact, as we have put a bigger focus for strong and sustainable pace, and now with more focused work, we must not mix it with a comfortable pace. The purpose here is to ensure we can consistently ship stuff, and do it better each time. If we are not challenged once in a while and don’t take the opportunity to surf the waves of opportunity and inspiration when they appear, we will greatly reduce our ability to evolve and have a growing impact. As in on other sides of life such as in fitness, emotional intelligence or creation, growth only comes from hard work and a bit of suffering once in a while.

We need to see strong and sustainable not as a comfortable pace but instead a healthy mix of jogging and sprinting, that keeps us challenged and growing while ensuring it is healthy and sustainable.

On project scope

We already discuss more frequently if we are really gonna need that functionality before doing it, which has been a big progress in this matter, but we should make a habit of doing it always.

A more relevant part that we don’t do enough is discussing when should we remove functionality, so we can move faster and maintain less code.

Related reading: https://m.signalvnoise.com/are-you-making-customers-too-happy-9b2236231365

Wrap up

What tactics do you use to limit WIP and focused experimentation on your daily work?