Raise your hand if you’ve heard this one before. Developers are very expensive, they need to be coding 100% of the time. I bet 9 out of 10 of you have their hand in the air. At least in your mind.
As a former IT Manager, I understand the desire. But here’s the thing, this desire can be damaging to delivery.
A Story of Two Patients
Let’s step away from software development and talk about two medical patients. Both are seeking a diagnosis for a potentially serious condition.
Patient 1
As Patient One (P1) you encounter a healthcare system many of us will recognize. You want to schedule an appoint to see your primary care doctor. Since your condition may be serious they get you in later that day.
You get to the clinic, sign in, and wait some more. Then you see a nurse in a treatment room. The nurse takes your vitals and asks some questions about the reason for your visit. This takes 10 minutes.
Then you wait some more for the doctor, an additional 15 minutes of waiting.
After a 15 minute consultation you receive a referral for further tests. It takes 2 days to have the tests completed. Then you wait another day for the results.
After a 15 minute call to discuss the results you receive a referral to a specialist. Of course it takes a couple weeks to get an appointment with a specialist so you wait another 14 days.
To receive the final diagnosis from the specialist takes 30 minutes.
Totaling all that up gives us:
- P1 time spent receiving care: 10 minutes (nurse) + 15 minutes (meet doctor) + 15 minutes (test results call) + 30 minutes (specialist) = 70 minutes (1 hour, 10 minutes)
- P1 elapsed time to receive a diagnosis: 19 days (initial treatment, waiting for tests, waiting for test results, day of receiving results) = 456 hours
- Flow Efficiency: 0.26% (1.17 hours/456 hours)
What this is telling us is that less than 1% of the elapsed time to diagnosis is spent adding value (medical care). The rest is waste (waiting).
Patient 2
As Patient 2 (P2) you encounter a healthcare system very few of us will recognize. You want to see your primary care doctor right away. Similar to P1, with a potentially serious condition you are seen immediately.
You get to the clinic, sign in, and walk to a treatment room. In the room are the nurse and your doctor. The nurse takes your vitals and the doctor asks you some questions.
After a 15 minute consultation you discover you need another test. Then the nurse walks you to the in-office lab where testing is immediately performed. The results confirm you need to meet with a specialist.
Another walk down the hall and you meet with the specialist. You receive your final diagnosis in the next 30 minutes.
Totaling all that up gives us:
- P2 time spent receiving care: 15 minutes (doctor, nurse) + 30 minutes (specialist, test results) = 45 minutes
- P2 elapsed time to receive a diagnosis: 1 hour
- Flow Efficiency: 75.0% (45 minutes/60 minutes)
What this is telling us is that 75% of the time the patient is receiving value (medical care).
Resource Efficiency vs Flow Efficiency
The story of the two different Patient experiences illustrates a difference in goals. The first scenario describes an environment that values Resource Efficiency.
In this system the primary goal is to keep the expensive resources busy at all times. Since the doctors and specialists are continually seeing patients billable hours are maximized. However, this comes at the expense of customer experience, which is far worse in this scenario. It takes weeks to get a diagnosis.
The second Patient experience illustrates a system that values Flow Efficiency. The primary goal of such a system is to reduce the amount of time spent within the system. In this case that results in maximizing the customer experience. The diagnosis was completed within one day.
What made the P2 Patient experience far better was that there was slack in the system. Health care professionals could respond immediately to new patients. There was no queue of existing patients waiting to be seen before P2.
Slack Reduces Delay
Getting back to software development, consider work items that flow through your processes from the Patient lens. Would those work items (Patients) label your policies as valuing Resource Efficiency or Flow Efficiency? Are they flowing smoothly through your processes or are they experiencing long wait periods?
Do policies exist such as developers must always be coding? What that is doing is causing work to pile up before that particular skill state. A queue is building, perhaps unseen as the work is recorded in a tool such as Jira or ADO, rather than visible as patients in a health care waiting room.
In order for developers to always be busy there must always be work waiting for them. Once they finish something they immediately move to the next item. Anything new must wait its turn in the queue. If you have multiple such skill silos you will have multiple queues within the system. Each queue adds to the overall wait time.
Always remember: Every handoff involves a queue. Every queue adds to wait time.
In order to reduce these wait times, and increase delivery flow, slack must be introduced at the specialty skill silos. Specialists must have time available within their day to respond to unforeseen circumstances or new, unexpected work. They need time to innovate.
The smoother the flow of work through the system, the higher the predictability of that system. Reducing the size of, or eliminating, wait queues results in a smoother flow of work.
That’s not to say people will be sitting around doing nothing. Instead, activities that are easily interrupted are performed. Examples would include time for learning, mentoring a colleague, updating online documentation, cleaning up test suites, helping a teammate with other incomplete work. I’m sure you can think of plenty more. Treat them as professionals and I’m sure they will respond accordingly.
Look for Signs
Unlike patients sitting in a waiting room, or a multi-week lead time to see a specialist, you might have to dig a little to find queues within your system. Teams are good at hiding them, typically as a result of responding to overvalued busyness.
Things I’ve seen:
- Overly broad workflow states: At the extreme, this would be a state such as “Doing” where everything to transform a work item from beginning to Done happens. This might be great if the team is mobbing or ensemble programming but could also be a place to hide handoffs (queues). Consider adding a measure for time spent in each state, such as adding a dot to a card for every day it is within each state. Combine this with an Aging WIP Standup.
- Narrow workflow states: The opposite of overly broad states, having a state per technology layer and/or SDLC step will add to overall wait time. If the team is not working collaboratively, on vertically sliced stories, this will likely occur. Look for workflow states such as “Front End Dev” and “Testing” and buffer (wait) states in between. Collaborating on work items using pairing or mobbing would be a recommended approach.
- Individual work items per specialty: Look for “horizontally” written backlog items, such as “Front End” work or “Testing” work only. These are often to ensure certain skillsets are always busy. The downside is they add risk and an imbalance to flow. The added risk is from late integration and review of the complete functionality (after the back-end coding and testing of the integrated work is done).
- Cherry picking specialty work during Sprint Planning: Closely related to the item above, listen for statements such as “We need a story for Steve” where Steve is a Front End or Back End developer who only works on that type coding.
- Splitting boards: The most common approach is to split development and testing to separate workflow boards. Rather than having a queue/buffer, often labeled “Dev Done”, between coding and testing the board is split. That hides the untested work in an unbound backlog rather than in a buffer state on a full team level board. Favor WIP limited (bounded) buffer states over unbound backlogs which hide the excess inventory of incomplete work.
Value Flow over Resource Efficiency
The primary challenge with keeping specific skills busy all the time is that it creates an imbalance in the flow. Work must always be available for those specific team members. The result is that they will start more work than the rest of the team can finish. There will be a queue in front of them, so they have no downtime between work items, and there will be a queue after them because the rest of the team is busy finishing other work that was already in-progress.
Every queue adds to wait time. inhibiting flow. Finding and reducing wait periods in the workflow will reduce your Lead Time, which will result in happier customers.
Work with the team to find work that is sitting at rest. This is where the “big wins” are found to unlocking flow and increasing predictability.
Reduce and remove buffers and queues to the extent possible. Measure progress by reviewing cycle and lead times. Both should be improving with efforts to reduce work at rest.
There will be a balancing point, unique to each organization, at which flow improvements will cut too deep into people having enough value add work to do. Use experiments to find that balance which works best for you. See the image below, you are targeting somewhere along the line in the upper right quadrant.
Most organization change efforts, in order to keep people and teams 100% busy and completing work as fast as possible, create Efficient Islands. However, it’s a very rare team that comprises the entire value stream. With efficient islands, work will be at rest for potentially long periods of time while waiting for the next efficient island to have availability.
Spuddle (17th Century): To work ineffectively; to be extremely busy whilst achieving absolutely nothing.
Remember the medical systems described earlier. The doctors work very quickly (efficient islands) but the patient is waiting for long periods of time between short bursts of effort in the first scenario. This is what happens within your organization when change efforts target “teams going faster” (an Agile misconception).
Additional Policies Slowing Delivery
- Narrow job descriptions and strict responsibilities. This can cause skill siloing within the workflow. Team members won’t step out of their role to help others. This creates handoffs and each handoff means a waiting, or buffer, queue. Work sitting in a queue slows delivery every time. If you’ve ever heard someone say “stay in your lane” this is happening in your system. If you have a RACI, throw it away.
- Individual performance evaluations. Like the above, measuring individuals promotes individual behavior rather than teamwork. People will be less likely to help others if they feel their metrics would not be as positive as a result.
Manage the System, Mentor the People
After a short period of time of learning to work together, it’s usually not the teams, it’s the system and related policies, which create inefficiency in delivery. As an IT manager, the system is largely your responsibility. To create an environment where individuals and teams can perform to their abilities.
Utilize your experience, leverage your management capital, to transform the system. Use flow data and metrics to monitor improvement experiments. Empower the team to reduce waste.
Mentor and help team members grow in their knowledge and skills. Teach them the power of scientific thinking and experimentation to continuously inspect and adapt their environment.
Move away from creating efficient island to seeing the whole system. That’s where the big wins are.
If you liked this post and want to learn more about Agile, Lean or Leadership, please consider purchasing a book from my Recommended Reading page.
Until next time!
