Here are two sentences that I sometimes hear from developers.
- "We are always starting new features but we never finish what we have already started", and
- "Because of the WIP limit I feel so unproductive. I can't start work on the next important feature."
Right now it might seem obvious that these statements contradict each other. But during day-to-day work, this might not be as obvious as it seems. When we adhere to WIP limits we make sure that we finish tasks before we start new ones. This solves complaint (1) but also generates complaint (2). If a developer cannot start another topic right after she finishes what she worked on then this can make her feel unproductive.
TL;DR
In a world of deadlines and never-ending backlogs of tasks, it's easy to think you're being productive when you're merely busy. What is important to understand is that:
- Being busy neither means that you're doing the right thing nor that you're doing it right,
- The goals you set for the team must not contradict the goals you set for individuals, and
- That making sure people don't have something to do all the time will get more tasks done faster
Busy ≠ Productive
A common mistake people make is to think that being busy is the same as being productive. I can relate to that because I have fallen into that trap as well in the past. Crunching through work for hours and hours can make me really happy. It gets problematic though when none of the work we do relates to a goal that we or our team aims to achieve. If all that you are doing is keeping your hands busy typing then what good does that do?
Being productive means doing something meaningful. This isn't related to how complex a task is or how much time it will consume. You can be productive working on a task for a week but you can also be productive when that task is done within an hour. The important part is that you make sure that every action you take will get you closer to the goal you want to achieve.
You cannot be productive without setting goals
When you don't know where you are going, how will you make sure you arrive at the right place?
I understand that defining a clear goal can be a hard task. Why? Because the goal might not turn out to be what we initially thought it would be. Since we're all human we tend to not like to do the things that force us out of our comfort zone. We can achieve this by not setting goals. If there is no goal then we can claim we've reached it at any point. While this might make us feel good about ourselves we need to understand that it won't help us in the long run.
Different kinds of goals
If you think about your last day at work, what would you consider goals? Working on a user story? Doing a refactoring? Ticking off the action item from the last retrospective? Implementing one test case?
You might have never thought about these items as goals. Maybe you have even wondered why they exist in the first place? We're doing this exercise of slicing problems into smaller pieces to have items we can work on. Frozen II featured a whole song dedicated to this topic! That is, for instance, why a user story needs to have acceptance criteria. Without them, how would we know when the story is done (i.e. the goal is achieved)?
One of the smallest goals I could think of is a test case. That is probably also why I like TDD so much. Whenever a test goes from red to green I know that I've achieved this particular goal. If I've written and implemented all the tests that make up a user story I've achieved the next larger goal.
When we work like this we focus most of our energy on tasks that are essential. This means we're wasting as little time as possible on tasks that do not help us achieve a goal. And this means we are productive!
I encourage you to use this argument any time someone claims that writing tests make you slower. That's a fallacy for another post though.
Team productivity / Individual productivity
If your organization correlates promotions with personal goals then you might be in trouble. Because personal goals do not always align with what a product or the business needs to achieve. In this respect, developers might work against any change to your development process that prioritizes the team over the individual. While I can understand that managers need some way to evaluate developers there need to be betters ways.
This is not an unsolvable problem. What is important is that you are aware that you might be motivating people to do the thing you don't want them to do. How can you fix this?
Individual goals need to be in alignment with team goals
I believe what is missing in a lot of scenarios are clear goals for the team as a whole. Team goals must be about more than story counts, cycle times, or the number of bugs. They should directly connect the work of the team with the value it creates for the customer. Don't get me wrong. Counting stories and bugs might help to measure the success of a certain goal but they should not be the goal. In the end, what does it mean to achieve super-fast cycle times with no bugs if nothing of what you have built helps your customers?
OKRs might be one way to achieve a hierarchy of goals while also aligning them with each other. You'll need to choose what works best for your team. The important exercise is to be aware of the goals and make them visible. Because after you have done that it becomes easier to see when a goal you set for a person contradicts a team goal.
Provide people with the space to work on individual goals
Now that we have acknowledged that there are different kinds of goals we need to make sure that there is room to achieve them. If your development process is optimized to solely contribute to team goals then you're sooner or later going to run into problems when people work on their personal goals. Some agile methods have introduced the concept of Gold Cards for this purpose. Developers can use them to opt-out of day-to-day work and work on a personal topic instead. My personal experience tells me they are rubbish, though.
When your development process aims at keeping everyone busy all the time it can be hard for a developer to use one of her gold cards. I've noticed that this is sometimes caused by a feeling of "letting the team down". Because when there is so much to do, aren't I selfish if I'd use a gold card?
If this happens it might be a sign of overutilization which I'll explain in the next section.
The cost of overutilization
The last two sections were mainly about the point (1). The feeling of not being able to finish a feature can be resolved by creating and communicating clear goals that the whole team agrees upon. While there might still be some frustration it can help the developer understand why the team is acting in a certain way.
Now, we're going to talk about all the work you should not do. If I would be an evil manager I would claim that "A team only performs well when everyone works on something all the time." This YouTube video does a great job demonstrating why this is not true. To avoid people being busy all the time Kanban introduced WIP limits.
However, if not everyone is busy then some people will have nothing to do from time to time. This can make them think that they are unproductive because they confuse being busy with being productive. The book The Phoenix Project provides an explanation that I find useful1.
Imagine a developer that works on planned work 50% of her time. This means there is a ratio of 50/50 between the time where she is busy and the time where she has nothing to do. We are going to use this as our baseline of 1 (because 50 divided by 50 is 1). If we assume that she is busy 90% of her time then the ratio changes to 90/10. What does this mean? This means that if something unexpected happens (e.g. a critical bug on production) it will take her 9 times as long to work on that task. In other words, by keeping everyone busy all the time we're leaving no room for the unexpected. When we don't expect the unexpected then every bug, security issue, or other kinds of incidents will disrupt the team's productivity. The extra cost of context switches will then make the scheduled tasks also take longer. I think we can agree that this is not a situation we would like to be in.
WIP limits
I've mentioned WIP limits a couple of times in this article. They are a tool you can use to prevent the team from being overutilized. In my team, when we set WIP limits we tend to pick a number that makes us feel a little uncomfortable. We do this because raising the limit is easier than reducing it. We also make sure that we make this a topic in the next retrospective to check whether the WIP limit works or is harmful. So far, we have never raised a WIP limit.
At this point, you have made sure that your team can react to unplanned activities without disrupting the overall flow. But you've also created a void. Free time is something that can feel weird in the beginning. It might even lead to some frustration as shown in the statement (2). That is why I would recommend that you and your team come up with a list of activities developers can take up when there is nothing to do.
Slack time as a forcing function
One thing I've learned is to give developers some example options of what they could do when the WIP limit prevents them from starting something new. They could:
- Pair program with a peer to get their work finished faster,
- Do a refactoring that wasn't planned but would be nice to have, or
- Write a blog post (guess who's doing this right now)
The important part is that any of the other activities, while they are nice, aren't critical.
When a critical bug happens then a developer can exit a pairing session, pause that refactoring, or stop blogging at any time without harm.
By not being busy all the time we gain flexibility (dare I say agility).
This might seem like a super power from the outside.
Hey, this team is working so hard smart that they can react to bugs and requests at any given time and they still deliver on their deadlines.
Even though this might sound awesome in theory you need to make this visible to every single developer. Because in the end there will be situations where the best thing to do is to watch a video on YouTube. This can be frustrating for some developers. When they bring that frustration up, hear them out, show them the numbers, and never be too tired to explain that "the needs of the many outweigh the needs of the few, or the one".
Doing less as an individual so that the team can achieve more is what I call the productivity paradox.
Footnotes
-
If you want to learn more about this then I recommend reading The DevOps Handbook. ↩