Churn in Software Development

Churn – To be turbulent or agitated

If you’re struggling with missed deadlines and unreliable schedules on your team, there could be an issue with churn in your process. There are two primary causes of churn that, when present, will drive CEOs and other people relying on the product absolutely crazy:

Constant priority shifting and unclear desired outcomes.

Let’s explore each in depth and talk about how you remove or mitigate their effects.

Constant Priority Shifting

Every developer ever in the history of software has been on a product team where the finish line is constantly moving. I don’t mean in the agile / MVP way where you build something, get feedback and adjust. I’m talking about at times daily whiplash of “the most important thing we need to get done.”

Here’s why this kills productivity and blows out your calendar:

  • The cost of task switching, both at an individual and group/team level is massive. Working on one part of the application one day and another part the next day never allows your engineers to get into a groove. As a result, there are bits of functionality half-done all over the application, and there’s constant “Now where was I on this?” kind of activity going on.
  • It breeds lack of confidence. I’ve been in many meetings where developers will ask “Who’s making the decisions around here? Do they have any idea what they’re doing?” Where there is lack of confidence, there is lack of full effort. It’s human nature.

How do you mitigate the effects of this on your team?

  • Be vigilant about what makes it onto your roadmap. I will often ignore the first two or three requests for something to be added flat out. If someone keeps asking beyond that, it’s likely important enough to at least have a conversation about.
  • Be extremely vigilant about introducing unplanned work into your sprints or work queues. Yes, you have to allow for some unplanned work to come up, but often times asking a few more questions about the actual severity of the item in question will make it clear that the world’s not actually going to end if it isn’t addressed right away. It’s very different to ask your team to review what needs to be done to fix something as opposed to actually having to fix it. One takes an hour or two and can be done during coding breaks. The other is very disruptive
  • Have very clear criteria about what constitutes a worthwhile interruption of your team. If those criteria are not met, leave them alone. Period. In spite of  your insatiable desire to interrupt with random questions.

Unclear Desired Outcomes

This one is a killer. If your team starts work on a new feature and there’s no clear finish line, you pay a heavy price in time and quality.

Here’s what typically happens:

  • A designer puts together wireframes based on what they’re told from the product owner about the requirements
  • Everyone signs off that, yes, if it works like this, we’ll be spot on
  • The developers go and build it to work like it was designed
  • Everyone starts using it and realizes they had it wrong from the beginning
  • Start over

Round and round you go. Meanwhile the feature never gets released, nor does anything else behind it. Everything gets pushed back, and it cascades. Soon you’re missing deadlines by a mile and no one can tell you why.

How do you fix it?

  1. Start paying attention to the work being done. Embed yourself in the next sprint and pay attention to the back and forth. Is the team revisiting the same issue or same feature over and over?
  2. Start asking questions such as: “Is it working like we designed it?” If your answer is yes, then you have a problem upstream from the actual building of the product. It might be that the requirements aren’t clear, or your designers aren’t properly capturing the requirements, or some combination. Regardless, your most important job is to adjust so that when you get to building software, you know that if you get back what you asked for, it will be right. If the answer is no, then there’s an issue between design / requirements and your engineering group. You need to then dig in with both sides and get to the root of why you’re not getting what you asked for.

When this is going on, consider putting in a more strict gate on the build phase of a new feature. Perhaps you have to approve every design for a while. Or you may need to change out personnel.

Many times it’s simply a willingness to understand and listen that will solve both of these issues. However, if you’re the cause of shifting priorities, you may need to put a buffer between you and your team to ensure you have someone who will tell you “no.”

If you’re feeling churn in your process, and it feels like everything’s too slow and unreliable, dig in and see if you’ve got an issue with your priorities or how you’re communicating the desired outcome, then get to work fixing it.