Premature promotion

(I've got to say that this was meant as an internal memo, so there might be references that will sound weird for people outside my company.)

There are always a thousand ways we can improve our sprints — and when I talk about sprints, I'm referring to agile sprints. Unfortunately, there are also a thousand ways to divert our focus and never get meaningful progress. I've witnessed this over the years where a lot of good intentions never catalyzed in good results. It is beyond my purpose right now to determine why this happens, but I'm going to assume that zeroing in a particularly problematic area and doing everything we can to fix it before moving on will help us get ahead.

And then the problem turns into finding what's that area that will give us the most significant boost. I'm sure you have different ideas, but I want you to think about this one: the current most significant source of inefficiencies in our sprints is the premature promotion of tasks on the board.

(And of course, your mileage will vary and you could be in a different stage, with different problems. Please, don't take it personally when I generalize.)

What is "premature promotion"?

Task promotion refers to the movement of a particular task — or story — from one column to another closer to the finish line. In an agile board, columns are visual artifacts that represent the individual processes in the lifecycle of a task. Premature promotion happens when a unit of work is moved out of a process — or column — without being completely ready.

The most pervasive example of premature promotion in our sprints happens in the transition of work from development to quality assurance and creative review (In my company, we have two different processes guided by QA folks and UI designers.) The problem is not exclusive to this area, but the difference is enough to make everything else irrelevant.

Why does this happen?

When you think about a sprint in terms of different disciplines that collaborate in a task by moving it through the corresponding processes, it is tempting to create virtual walls between team members that reduce the sense of ownership. The goal goes from completing a task — not important anymore — to moving the task to the next person in line — what everyone cares about.

It is also common to see quality assurance and creative review as two safety net processes that will catch anything and everything that's missed during development. Nothing wrong with this, until developers start accelerating to meet their goal — moving a task — trusting that their lack of attention will be caught down the line by the other processes.

If we really care about moving things through the board really fast, we can't blame people for giving us just that.

Is this really that inefficient?

Moving an incomplete task forward is akin selling a car that needs to be recalled two years down the line. By the time it comes back, it is incredibly costly to fix, not even counting the damage to the reputation of the maker.

Here are three of the variables that play a significant role in all the time that's wasted when promoting a task prematurely:

  • Mental context switch every time a team member has to close a task, do something else, and then come back to the same task. This affects everyone involved in the sprint.

  • Downtime while the task moves from processes and waits for somebody to pick it up, acquire the necessary context, and then start working on it. The more the task moves back and forth, the more downtime we incur.

  • Environment setup to accommodate the specifics of particular tasks. This varies from project to project, and include things like branching, deployments, versioning, database state, among others.

How can we measure the actual impact of prematurely promoting tasks? We can certainly generalize to come up with a reasonable estimate that will give us an idea of how wasteful this is.

Let's think about "setup time" as everything involved in having a team member ready to start working on a task efficiently. For our purposes, setup time will only capture the time that we consider wasteful. A particular task that bounces back one time from quality assurance and one time from creative review requires us to factor 4 times the setup time:

  1. Quality Assurance finishes reviewing the task and moves it back to Development.
  2. Development finishes the changes requested and moves the task back to Quality Assurance.
  3. Creative Review reviews the task and moves it back to Development.
  4. Development finishes the changes requested and moves the task back to Creative Review.

How long do we think the setup time is? This varies from task to task, but to be conservative, I'm going to assume that 15 minutes is a good start. Doing the numbers, our task above incurred on 1 hour of wasted time.

Now imagine a sprint of work where a 5-person team tackles 50 different tasks, and imagine that we rack 1 hour of wasted time for each task; the total waste is equivalent to adding more than one extra member to the team!

Of course, all of these numbers are relative to the project, team, cadence, culture, complexity, and whatnot. The point, however, stands: premature promotion of tasks is one of the most significant contributors to the inefficiency of our teams.

What can we do from here?

There's no silver bullet to fix this problem, and it will likely require a lot of focus from the team along with different techniques to minimize the issue.

Fortunately, a good start is to increase the attention to detail of tasks during development, which is not necessarily hard to accomplish. As long as people are aware of the consequences, they will likely get onboard and actively try to fix the problem. Here are some ideas that should see some success:

  • Remove any narrative that foster silos within the different disciplines that work together in a sprint.
  • Improve the definition and acceptance criteria of tasks.
  • Improve the collaboration between developers and quality assurance personnel to make sure they are both working in tandem.
  • When possible, remove artificial obstacles that prevent tasks from being worked on simultaneously by different disciplines.
  • Promote the importance of an increased attention to detail within every individual process.

Conclusion

Every time we look, we see multiple ways to make things better. Our capacity to find problems is great, but it can also hinder our ability to make things happen. Focus is a precious commodity that we should use to help us drive progress. Improving our production sprints is no exception.

From the center of all the little things that could be better, prematurely promoting tasks looks like one of the main factors that reduce the efficiency of our teams. Identifying ways to reduce the problem will yield substantial benefits to the process, the team, and your company overall.

Have something to say about this post? Get in touch!

Want to read more? Visit the archive.