If you’ve been managing highly specialized teams, you’ll certainly have seen how specialization dictates the priority of the work. Worse yet, it often creates road blocks preventing your team from delivering results quickly and efficiently.
The fact is, specialization decreases flow. And the combination of specialization and significance within a team can be a particularly devastating one.
Today, we’ll explore how specialization affects your overall performance. And If this is something that impacts your business outcomes, I’ll give you some actionable advice (that you can apply as early as tomorrow morning!) to address this challenge.
The Dilemma
Let’s analyze the following scenario. This is the Aging Chart of a development team of one designer, 2 front-end developers, 2 back-end developers and one QA specialist. Their process consists of the following states: Development, Code review, Code review (Done), Testing, Testing (Done) and Deployment.
This team has implemented a Kanban pull system. All their “Done” states are queue states. These states are used to communicate that the work is ready to move on to the next state.
The CONWIP of the system is 10 work items. CONWIP refers to constant work in progress or simply put, the max number of work items in progress that are allowed to stay in the system at any one time.
At the current moment, there are 5 cards in Code Review (Done) waiting to be handled in the Testing state. No one is working on them, they are just sitting and aging in the process. The team is currently working on 8 work items in total, so they actually have the capacity to handle 2 more tasks.
Now, my question to you is: “Should the team start new work in this situation?”. They still have two more slots free before they reach the WIP limit of the system. As the developers have the capacity to do more work, should they pull new tasks into the Development state?
Your Delivery Rate Has Been Limited
Here’s what’s actually happening. There is a ridiculous bottleneck in the Testing state. It’s obvious that the QA specialist is not able to handle all the work that has been produced by the developers.
The results? The team can only deliver at the speed of the slowest step in the process – the testing phase. The team’s performance is now limited by the performance of the testing state.
So, given this perspective, would you say it makes sense to start new work? Would that action make any difference to the delivery rate of the system, or rather, wouldn’t piling more and more work items in front of the Testing state make the problem worse?
The best approach for handling this scenario is to stop starting and take people who have the most availability and allow them to make a contribution to the work of the people who have the least availability. This will soon enable the flow of work to resume.
Calling Back-up
Let’s put the pedal to the metal. Would a developer be capable of testing? Does the developer actually have the skills to help with testing?
Yes, and if they don’t, the difference between the skills they have now and what they need to have is probably narrow.
Of course, to make this work, there must be some rules applied. For example:
- Developers should not test their own code
- The QA specialist decides what the developers test and how to test it
- The QA specialist reviews the work of the developers
- The QA specialist is the only person who have the authority to move the work further into the workflow
Let’s explore another example. Let’s say that the PM is helping with the customers’ onboarding process and she is not available to schedule the work for the next iteration. As a result, the system is starving.
So, could a designer help refine cards in the upstream process to help bring some clarity and prepare the work for development? Of course, they need to follow the established explicit process policies to move the work down the funnel, but it’s very likely that the designer will be able to handle that.
There is more happening here than simply encouraging proactive behavior. This approach is actually going to help the team develop new skills and become more empathetic, more engaged with the concept of flow to actually help deliver results in the most efficient manner.
Helpful and Not-So-Helpful Behaviors
The behaviors that I see teams display, which makes them so resistant to handling situations like this effectively, are usually related to specialization. Because underneath specialization, there lies a strong sense of identity for an individual, which makes them feel significant and valued.
If you are the only person in a team that has a very special craft, people engaging in your activities will make you feel less significant.
Although I like the idea of people having special skills, the thing that I don’t want to see is scenarios where only one person can make a contribution to a certain problem that is waiting to be solved. Worse yet, what you should really pay attention to is when subject matter experts are resistant to sharing their knowledge.
This is a situation where specialization can actually cause a really bad character trait. So, when you spot this reluctance, you have to call it out.
When I’m working with highly specialized teams, I often resort to one of my favorite conversations – getting them to check their titles. Just because someone is called a front-end developer, this doesn’t necessarily mean that they are only doing front-end work. Yes, they may do that job for the majority of the time, but often the feeling of specialization is self-imposed. And what I’m trying to show them is that they are the only people who perceive themselves this way.
From a business perspective, having individuals only work on tasks that are suitable for their special skills is disruptive, because either the start of the work is artificially delayed or once started, the age of the work gets tightly coupled with the availability of the specialists. In both cases, we are delaying the work and missing opportunities for improvement in the long run.
Now, here is a very simple step you can take (as early as tomorrow morning) that will help you focus on the outcomes of your delivery system and let your team self-organize around the work!
Introduce an explicit process policy outlining how the team should manage their work in progress. It could look like this:
“Once you finish a work item, instead of immediately pulling a new one from the backlog, first, go through the cards on the board. Start from the far-most right side column, then go towards the beginning of the workflow.
Look for items that are not assigned to anyone, any issues that need to be fixed (even if they are not assigned to you), anything that’s waiting for code review or implement feedback from code review.
A new item of work should only be started if there is literally nothing that you can do to help the ongoing work items move forward in the process.”
Observe how following this policy affects the team behavior and keep your focus on resolving the obstacles that prevent them from handling each other’s work.
It is important to help the team understand the goal behind this approach. Letting people help each other and focus on managing the work effectively will improve their delivery speed. Sharing knowledge and skills will not only increase their efficiency but it will also enable them to become a truly cohesive team.
Always remember, achieving sustainable business outcomes boils down to managing the work effectively. Delivering value to our customers is a mutual effort. Promote an environment of collaboration, trust and respect. That’s the ultimate approach to improving your overall performance.
And if you’d like to explore the proven roadmap to optimize your workflows for predictability and consistently deliver on time, I’d be thrilled to welcome you to our Sustainable Predictability program!
