Four Steps to Achieving Operational Flow and Improving Quality in Tech Teams

No matter the team or organisation size, there’s always more to do than is possible to get done. That’s why it’s so important for work to flow effectively. In this article, we will discuss 4 steps to achieving operational flow and improving quality in tech teams.

Unfortunately, work often doesn’t flow like a quick-moving river. It often sits, stuck in a quagmire, until somebody has the time to work on it. It doesn’t have to be that way.

Keep reading for 4 surefire tips to get work moving through your teams again.

1. Do Less

It sounds counterproductive, but the secret to getting more done is to commit to less work. Humans are terrible multi-taskers. The simple truth is that we cannot focus on multiple things at the same time. We are most effective when we work on a single thing at a time and do it until it’s done. Multiple different factors combine to create this simple reality:

• Context switching. We keep a lot of information in our working memory. When we focus on a single thing, a lot of the relevant context stays in our heads. When we switch to something else, we lose all of the context. The next time we pick that work up, we have to rebuild the context. The more often we switch, the more effort is lost to context switching.
• Cognitive Load. There’s only so much we can handle at one time. There are limits to what we can keep in memory. When we work on one thing, we can keep significant amounts of the relevant information to hand. If we have to work on 2 things, the amount of information we can hold is reduced by more than 50% (workload increase + context switching). The more stuff we have going on, the less focus we can give to any single piece of work.

I have coached leaders who found themselves going from meeting to meeting all day and getting to the end of the day without feeling like they had accomplished anything.

If that sounds familiar, you know exactly how this problem shows up.

Keeping busy feels productive, but often results in not finishing the things that matter.

Do one thing until it is done. Then do the next thing.

2. Remove Dependencies

Oftentimes, our work depends on people outside our teams. Sometimes we need a bit of information, while at other times, other teams need to complete their own part of the work before we can continue ours. As much as possible, we want to break this dependency.

If work is dependent on another team completing something, don’t start it until they’ve done their part. While the work may be your priority at the moment, it’s possible the other team has something else going on that is their priority. There’s no guarantee when they’ll start the work you’re dependent on, or how long it’ll take to finish once they start.

If the work is absolutely critical, and there’s nothing more important for your team, you can either a) help the other team get their work done, so they can focus on what you need, b) do the dependent work yourself, or c) architect the work so that the dependency goes away.

Removing dependencies is often a lot of work. Dependencies are often the result of specialist knowledge that resides in another part of the organisation, or past architectural choices. It often feels like the dependencies are inevitable and inescapable. There’s a lot of truth to the idea that removing dependencies will be painful and time-consuming, but they only have to be removed once, at which point the team never has to deal with that dependency again. It’s an investment today in order to get better results tomorrow.

A few years ago, I worked with a bank that dealt with dependencies by having big room planning sessions. During these sessions (which felt amazing to participate in, due to the human factor and buzz), the next quarter was planned out in as much detail as teams could manage. Dependencies would be identified and mapped, so it was clear where work would get stuck. Work from many different teams would often depend on a single team to get done (such as security approvals, or a platform team finishing something that others want to use). Multiple teams would often end up stalled, waiting for their work to be important enough for the team they were dependent on to do it. Often work would then be added to keep the team busy, but it was never as valuable to the organisation as the work that was stuck.

By contrast, I recently worked with a large enterprise that had architected all of its systems to be loosely coupled and independent. Each team had all the capabilities necessary to take on the work that was important to them. Dependencies simply weren’t a problem they faced. They could move at the speed the business needed them to, and the market allowed. They weren’t always like this. 5 years ago, they were in the same position as the bank. The key difference is that instead of managing dependencies, they intentionally broke them down.

Breaking down dependencies is a classic example of trading short-term pain for long-term gain.

3. Focus On Keeping Work Moving & Not Keeping People Busy

Work is not inherently valuable. In order for it to become valuable, it has to be in front of the right customer at the right time. Until that point, it doesn’t generate any revenue. That means that work that’s still progressing carries no value of its own. Customers don’t pay for us to be busy, they pay for us to solve their problems. What’s more, work that isn’t available to customers means customers can’t start paying for it.

The implications can be staggering. If work is only valuable once it’s in front of a customer, that means that work that’s sitting idle, waiting for somebody to complete it, has no value. Worse, work that’s sitting idle is losing money, because customers can’t start paying for it until it’s ready. The longer it takes to get ready, the more potential revenue is lost.

Therefore, the focus of the organisation should be on completing work (to a high standard) and getting it in front of customers. Given what we learned above, that means there’s very little value in keeping track of how busy people are. The most important metric to track is how long it takes work to move through the system, from start to finish.

What’s more, if there are dependencies across different areas, some of those areas should be idle. If our goal is to move work through the system quickly, then any time spent waiting for people to understand the context, put down something else they were working on, or finish something else, reduces the potential revenue we can generate from the piece of work we’re focused on.

Inevitably, that means that some people will be idle. In fact, it means that people being idle is absolutely necessary in order to get the most value out of the organisation and, therefore, the most revenue into it.

During the shift from high to low dependencies, the company I mentioned before had a period where dependencies were being broken down but weren’t gone, yet. In order to keep work moving, they decided what the highest priority work was, and whenever that work moved from one team to another, focus went with it. The result was highest priority work moved through the organisation in the shortest time, because it was every team’s highest priority, which meant it was always worked on first.

Contrast that with what I often see when working with enterprises - a focus on ensuring that everybody is busy, all the time. Whether it’s done by measuring utilisation or overloading the team, the result is the same. When teams are kept busy all the time, they lose the ability to react to changes, delays spiral out of control, and work slows down. Since we’ve established that work only becomes valuable when it is in front of a customer at the right time, work that sits idle, waiting for somebody to be free to work on it is, by definition, valueless.

The following is a real example from work with a bank. A website change was projected to bring in $200,000 per week and only required a week’s worth of work. It was delayed for 9 months due to sitting in another team’s queue, which was caused by a lack of focus and mismatched priorities. Revenue lost to the bank over those 9 months (~40 weeks): $8,000,000. If the team that was needed to do the work, instead of doing other things, simply sat idle, waiting for the work to arrive, it would have cost ~$20,000/week. It seems obvious that the financially savvy thing to do would be to have the team idle until the most important work comes up. Don’t distract them with secondary work - the numbers just don’t add up.

The more work there is that’s waiting to be done, blocking other work that’s also waiting to be done, the more unrealised value (ie money) is lost.
Focus on keeping the work moving.

4. Remove Silos

Getting rid of dependencies is a start, but sometimes it can be difficult. If a team needs knowledge that doesn’t exist in their team, or needs work that only people in another team can do, there’s a natural dependency. The traditional approach to resolving that is to ask the other team to do something and wait until they do it.

It would be much faster if we took another approach, and put every skill necessary to move work through the entire system into a single team. The team would then have the ability to complete everything it started. It doesn’t have to depend on another team, and nobody should depend on it.

A health insurance company I worked with a couple of years ago was struggling with delivery. They hadn’t in the past, and wanted help figuring out what was going on. During our investigation, we discovered that the new operating model they had adopted included separating the building and running of software. When the teams that had built software supported it:

• Quality was higher
• Response times were faster
• Fewer things failed, and
• More work was delivered.

The change, while logical on paper, added a handover that meant:

• Support teams didn’t understand the software, so had to disrupt delivery teams to get help
• Delivery teams forgot about the software they were being asked to help with because they’d moved on to something new
• Handover docs took up a lot of time
• Handover docs were always incomplete (this is inevitable)
• Some things were missed
• Planning failed to account for the time that delivery teams would spend supporting support teams, which meant every piece of work ended up under time pressure

The same change meant that database changes and queries were no longer easily accessible, which introduced another set of delays. In fact, the only team that was unaffected was the mainframe team, because nobody understood what they did, and they were left alone to get on with things.

Had the team structures stayed the way they were, the health insurance company wouldn’t have gotten a shiny new operating model ... and also would have been able to deliver what customers wanted.

If there are 30 skills necessary to get work out the door, then your effective team size is 30, regardless of the org structure. It’s far more effective to adjust the org structure, and put everybody in the same team than it is to be beholden to the structure and make everybody work around it. Once everybody is in the same team, and work begins to flow, the team can then think about how they can reduce dependencies and complexity, as suggested earlier.

Rather than arranging teams in functional silos, arrange them so they can deliver value independently. This arrangement then allows more work to move through the system simultaneously, because the different work doesn’t create delays for other teams.

Each of the above contributes to improving flow. But what about improving quality? The interesting thing is that each of the steps above improves quality, too.
By doing fewer things at once, the reduced cognitive load will make it easier for the team to produce higher quality work, while reduced context switching makes it less likely they’ll miss something important. When quality goes up, rework will go down, which ends up creating a positive feedback loop around both quality and speed.

Removing dependencies means the team can focus on what needs to get done. They won’t have to find something else to keep them busy while they wait for another team. That will further reduce context switching and cognitive load, allowing the teams to have a better idea of what they’re doing, why, and for whom.

Focusing on keeping work moving will remove busywork from the system. The reduction in busywork creates space that people can fill with learning, improving, automation, and other things that enable higher quality work, happier staff, better morale and, therefore, better results.

The best solutions to problems are found by groups with a diversity of thought, knowledge, and experience. By reducing silos, we create environments where people who work together every day see things from different viewpoints. They’ll be more likely to prevent errors, bias, and incorrect assumptions, as they’ll have a more complete view. In addition, there will be fewer handovers to other teams, which means fewer opportunities for information or knowledge to get lost. Quality will improve as a result.

Better flow and high quality can come about from a few simple changes in how companies think about and approach work. They’ll take time, and effort, but the tradeoffs are worth it. Work will flow, quality will improve, customers will get what they want, revenue will improve, and morale will be higher. It’s an investment of time that pays significant dividends, and continues to pay them in the future, as positive feedback loops are created and reinforced. The sooner it starts, the sooner the organisation will realise the benefits.

Adopting the 4 steps outlined above will change your organisation. Doing less means you can give more attention to what you are doing. Removing dependencies enables teams to be flexible and respond to the needs of their customers. Keeping work moving ensures that value will be delivered as quickly as possible. Removing silos ensures that teams can be collaborative and effective in their work. All together, they will make it feel like you’re working in a completely different company - one that produces quality products at a speed you wouldn’t have dreamed possible.

References

Reducing Cognitive Load in Agile DevOps Teams Using Team Topologies