Why we have target conditions instead of targets

Keep calm and be proud. That’s what we strive for here at Easy LMS. That sounds nice, but how do we get there? We manage by process, and not by results. We want our processes to improve, so we get better results. That’s why we use target conditions instead of targets. Although they sound the same, they’re totally different. We’ll explain why.

Target conditions and targets explained

Let’s start with a real example (from Toyota Kata: Managing People for Improvement, Adaptiveness and Superior Results) that you’ll probably recognize. You want to get up in the morning, and be at your desk within one hour. If this is your personal target, and you’re running late, then you have to rush. Maybe you speed while driving, skip breakfast, or don’t brush your teeth. Cutting corners to meet your target. If you define this as a target condition, you have to break it up into substeps that you can measure. If you don’t get to work in one hour, it’s not a problem, because you know which substep you can improve on. So, let’s break the target condition down to the following steps:

The outcome (the goal) of this process is to get to work on time, well fed, dressed, showered, with clean teeth, and without being rushed. That’s in everyone’s interest 😉.

Ok, but how do targets differ from target conditions?

A target condition is a description of the processes in your daily work when everything runs smoothly.

Back to some theory. We all know the feeling when work does not go as planned. Things take longer than you thought, or you run into hurdles along the way. A lot of things can go wrong. A target condition is a description of the processes in your daily work when everything runs smoothly. A target condition describes how we would like our work process and all its sub-processes to be. This is the future state of a process that you're aiming for. The target condition will give us a sense of direction for our improvements. How? We measure our work process while we work. Every time a process doesn't work as defined in the target condition, we have to look into that. We call that a 'root cause analysis'. We try to come up with a simple solution. Implementing this quickly brings us closer to our desired state.

Compare that to a target. A target should be met. You have to do everything in your power to get to the target, like in the routine example above. Which sounds like a heroic thing to do, right? Wrong. It’s stupid, in our opinion. Targets lead to stress, overtime, and disappointment about missed targets. It creates the opportunity to cut corners to get to your target. This is hurting quality and customer satisfaction in the long run. 

If you have to meet a target, you won’t invest in process improvements.

Besides that, if you have to meet a target, you won’t invest in process improvements. Process improvements only pay out over time. Time spent on improving will hurt your short-term results, of course. When you finally reach your goal, or miss your deadline, you can look back in retrospect at the things that didn’t go as planned. But, that will be days or weeks later, after the actual ‘misstep’ happened. Being so long ago, the trail will be cold, and you won’t have any actionable insights on how you can meet your target next time. You missed the opportunity to improve your process.

To sum up: targets hide your inefficiencies and learning opportunities, while target conditions help to make clear where you should improve, you're  observing and optimizing the process instead of focussing on the outcome.

If you find a small solution you can implement right away, you probably don’t need the big expensive solution at all.

How to use target conditions to improve

Get back to our morning routine example. The first morning you start measuring, you see that getting dressed takes 20 minutes. Now you have to do a root cause analysis. When you dive in, you discover that picking out your clothes takes 10 minutes. You lose 10 minutes there. So you come up with two solutions: 

1. Pick out your clothes the night before.
2. Buy a Porsche 911 to reduce traveling time.

Both sound like proper solutions. They get you to work on time. Right? Nope, wrong. Let me explain: 

1. If you’re struggling with getting to work on time, you have probably been advised to get your clothes ready the day before. But it’s not a real process improvement. Picking out clothes still takes 10 minutes. Why not go to bed 10 minutes earlier, wake up 10 minutes earlier, and spend the 10 minutes it takes? A real solution would be to reduce the time needed: wear the same shirt or turtleneck like Mark Zuckerberg does, or Steve Jobs did. Or wear the same set of clothes every Monday, and if you do the laundry, put those clothes together in a pile. Or reorganize your wardrobe so you have matching clothes go together in your drawers.
2. The solution to buy a car is too big. You don’t have the budget. The delivery time of the car is a couple of weeks. If you find a small solution you can implement right away, you probably don’t need the big expensive solution at all.

Let’s look at some examples from Easy LMS

At Easy LMS we strive for a single item flow.

At Easy LMS we strive for a single item flow. This means we want a user story to be able to flow smoothly through our development process without waiting somewhere on any other items to be ready. When we started working with this target condition, it didn’t work smoothly. The cycle, the time it takes between starting work on a new feature and getting it online, was 32 days. We started looking at the data on our work process to find out where to improve. We noticed that stories got stuck waiting for a release. Our release process was the first thing we wanted to improve.

Do two releases a week

We set the following challenge: get to a single item flow within a year. To get there we would have to set different target conditions to bring us closer to our goal. 

The first target condition we set was to get from one release every two or three weeks, to two releases a week. This felt almost unattainable: 

1. We started to plan two releases a week, on Tuesday and Thursday, and just see what we would encounter along the way. We sat down and described the steps needed to do the release, and who was responsible for what. 
2. The very first release didn’t go as it was supposed to. The developer who was responsible for the release was sick that day. The rest of the developers were assigned to another project. The solution was to automate and schedule the release so it didn’t depend on manual actions. The automation put the release on the staging server early in the morning on Tuesday and Thursday, ready for the acceptance test to be run by Caroline (QA/QC).
3. The next bottleneck we encountered was Caroline. She is responsible for finishing the release, but that day she was really busy managing the translators, to get everything translated from the previous release. We improved on our translation process, which is a whole different story, so Caroline would have more time to focus on testing. I hear you thinking, why not hire an extra tester? At that time we didn’t have the budget to hire an extra tester. Using targets it feels like a plausible solution to the problem, but hiring extra people is not a real process improvement. 

After two months, and a lot of small improvements, we managed to get to two releases a week. 

For the next target condition, we turned our attention to different parts of the development process. As we kept improving our work process, more and more stories would flow through the development process. As a result, the releases got bigger. Bigger releases take more time. Sometimes we couldn’t finish a release before the next release was ready. This made us miss the two releases a week target condition. 

How we got from two to four releases a week

To solve this problem, releases had to get smaller. We decided to set the next target condition on doing a release when four stories were ready to release. This resulted in  more frequent, smaller releases. Recently we raised the bar and lowered the number of stories in a release to two. We’re almost on a single item deploy. 

To get from two releases every two or three weeks to four releases a week is a huge advancement. To get there we did loads and loads of small improvements, and a couple of bigger ones, like automating almost all acceptance tests. 

Cycle time

As a result of those target conditions we brought the cycle time of a story down from 32 days to six days.

Along the way we defined and improved the description of the target condition, learned a lot, and reduced a lot of waste. As a result of those target conditions we brought the cycle time of a story down from 32 days to six days - with better quality code, less distractions, almost no hotfixes, and happier people.

What does this mean for our company culture?

1. We always say failure is not a bad thing, as long as you learn something. If we have a target condition in place, we actually know when we’re failing and what we need to learn. So failure leads to learning.
2. We are avid learners. Did we meet every target condition? Then we haven’t learned enough and we should set a new, stricter, more challenging target condition which sets us up for failure again. This brings us continuous learning. 
3. Learning is the most important target condition for us, to be a successful and sustainable company. Learning how to improve is the first step of this learning curve. 

Curious about our special work culture? Explore our Working at Easy LMS section to learn more!

Go to Working at Easy LMS