The value of idle time

The Product Backlog is a mandatory part of Scrum. Together with the Sprint Backlog, they define both the planned and upcoming work of the team.

There's a common assumption that it's considered good to have a decently sized product backlog, and as many items in the Sprint Backlog as the team has capacity to deliver. Let's examine this assumption by looking at a specific event.

The "no backlog" event

It was Tuesday evening. I had just a busy day behind me.
I was chilling, browsing the Web, when I received a message on LinkedIn. The following conversation ensued:

Mind Lukasz' last statement: "The most impressive customer service ever".
Why was this possible?

Had Lukasz contacted me half an hour earlier, this dialogue would never have happened. Why? Because I would have been busy, doing some other work. Lukasz would have had to wait. His request would have become part of my backlog.

Service Classes

There's a lot of work I am pushing ahead of me on a day-to-day basis.
But I classify my work into three categories:

1. Client related work - I try to cap the amount of client related work, to maintain a sustainable pace.
   It's a pretty stuffed backlog where things fall off the corners every day.
2. Spontaneous stuff - I do this stuff as fast as I see it, because I feel like doing it.
   The hidden constraint is that "as I see it" depends on me not being engaged in the other two types, because these take 100% of my attention.
3. Learning and Improvement - That's what I do most of the time when not doing Project work.
   I consider web content creation an intrinsic part of my own learning journey.

These categories would be called "service classes" in Kanban.
I am quite strict in separating these three classes, and prioritize class 1 work over everything else.

Without knowing, Lukasz hit my service class 2 - and during a time when I was indeed idle.
Since class 1 has no managed backlog, I got around to Lukasz' request right as it popped up, and hence, the epic dialogue ensued.

Service Classes in Scrum

If you think of the average Enterprise Scrum team, class 1 is planned during Sprint Planning, and class 2 activities are undesirable: all the work must be transparent in the Sprint Backlog, and the SBL should not be modified without consent of the team, especially not if this might impact the Sprint Goal.

Many Scrum teams spend 100% of their workload on class 1, going at an unsustainable pace, because the constantly descoped class 3 work warrants future-proofing the work.
Even if they plan for a certain amount of class 3 work, that is usually the first thing thrown overboard when there's pressure to deliver.

The importance of Spontaneity

Few Scrum teams take care of Class 2 work, and Scrum theory would dictate that it should be placed in the Product Backlog. This just so happens to be the reason why Scrum often feels like drudgery and developers are getting uncomfortable with practices like Pair Programming.

"Spontaneous stuff" is a way to relax the mind, it helps sustain motivation and being totally uncommitted on outcomes allows creativity to flourish.

Load versus Idle Time

As mentioned, class 1 is bulk work. As workload increases, the percent amount of class 1 activity quickly approaches 100%. Taking care of class 3 activity means that increasing load quickly diminishes idle time activity to go to Zero.

Since I already mentioned that idle time activity creates magic moments, both for team members and customers, high load with zero idle time destroys the "magic" of a team.

Wait Time Idleness

One source of Idle Time is Process Wait Time.
In a Lean culture, wait is seen as detrimental waste. This is both true and false. It is true when the organization doesn't create value during wait, while incurring costs. It is false when this wait is used to generate "magic moments".

Buffer Time Idleness

Both Scrum and Lean-Kanban approaches encourage eliminating idle time, as would the common "agile Scaling" frameworks. Team members are constantly encouraged to pull the next item. or help others get work in progress done faster.
This efficiency-minded paradigm only makes sense if the team controls the end-to-end performance of the process, otherwise they might just accumulate additional waste. Theory of Constraints comes to mind.

On the other hand, buffer removal in combination with a full backlog disenchants the team - there will be no more "magic moments": Everything is just plan, do, check, act.

Idle Time and Throughput

The flawed assumption that I want to address is that buffer elimination, cross-functionality and responsibility sharing would improve throughput. Maybe these will increase output, but this output will be subject to the full lead time of any other activity.

Backlogs vs. Idle Time

Genuine idle time means that the input backlog currently has a size of Zero and a parallel WIP of Zero as well. There is no queue: neither work-in-progress nor work-to-do.
An idle system doesn't require queue management. When idling, throughput for the next request is exactly equal to work time - the maximum throughput speed we could hope to achieve. This kind of throughput speed can look absolutely mind-boggling in comparison to normal activity cycle times.

The impact on organizational design

A perfect organization takes advantage of idle time points that maximize throughput speed - not efficient utilization avoiding idle time.

Summary

The conversation with Lukasz is an example of the benefits of having idle time in your work.
This kind of idle time allows for "magic moments" from a customer perspective.

Just imagine an organization where "magic moments" are the norm, and not the exception.
This requires you to actively shape demand: when demand is roughly equal to capacity, we can eliminate backlogs.
Demand queues destroy the magic.

Eliminate the queues. Make magic happen.

Scrum is setting you up to fail!

The amount of debates where agilists claim, "But Scrum addresses <this topic> already!" - then proceed to quote a sentence, or even a single term from their framework's rules are staggering. The phrase, "we need to be pragmatic, and Scrum is idealistic" heats up the debate.

My take: 

In some cases, frameworks like Scrum are helpful. By themselves, however, they aren't. They provide no helpful guidance and rely on the strong assumption that the solutions to an organization's core problems already exist within the team' sphere of control. 

This assumption is borderline insane, because people wouldn't need a rule or framework for something they know how to do.

Even in regards to my article about demand, I got the reply, "Scrum does address the issue. That's what you got a Product Owner for." and "SAFe uses the term 'Demand Management' at Portfolio level, therefore SAFe has a solution." - I say that this is about as helpful in practice as stating, "We have the cure for cancer already. That's what scientists are for: They even use the term cancer research."
Yes. And: What exactly is the solution to the problem beyond assigning responsibility or attaching a label somewhere?

Let's focus on Scrum, just to be talking about something specific.
In all fairness, many Scrum practitioners state, "Scrum doesn't solve your problems, it only highlights them" - which is my answer to everyone who would claim that "Scrum does address this already." Maybe you get a label. You don't get a solution. Scrum itself has no helpful answers, not even the hint of a direction.

Scrum's dangerous assumptions

Scrum makes a lot of strong assumptions. Most of the time, these assumptions are just not valid and will cause a Scrum adoption to shipwreck.
These are all examples of conditions that Scrum is simply assumed to have:

No blocking organizational issues

Scrum can only work when the surrounding organization is at least basically compatible with Scrum. Scrum's assumption is that you are well aware of how to ensure that:

• Organizational processes are fundamentally compatible with agile development
• A meaningful portfolio strategy exists
• Demand funneling "somehow works"
• Individual incentive schemes don't get in the way of team or organizational goals
• The organization improves where it matters
• You have stable teams

And what if not?

Unproblematic contracts

Scrum teams must operate in an environment where developers and customers share common goals, and developers are contractually enabled to maximize organizational value. Scrum assumes that you have a contract situation where:

• There is no functional split between different organizations (e.g. outsourced manual test - or worse, outsourced users)
• Financial incentives encourage optimizing around value rather than activities
• The team meets all legal requirements to deliver all required components
• The development organization benefits from producing better / more / faster outcomes

And what if not?

People get along

Scrum assumes people can and will communicate with a goal to create value.
You have to know by yourself how to achieve the following states:

• No communication gaps where significant information gets lost
• Stakeholders care and show up to provide essential feedback
• Managers understand and avoid what demotivates the team
• People have a sufficient level of trust to raise issues and concerns
• When all things fail, people focus on learning and improvement, avoiding blame.

And what if not?

Development issues

Since its inception, Scrum has removed all aspects of technical guidance. As such, there's now the hard assumption that:

• Teams have the necessary skills to produce a "Done" Increment
• Teams know about quality engineering practices
• The team's software isn't a steaming pile of ... legacy
• Teams are able to produce a meaningful business forecast
• Teams can cope with technology shifts

And what if not?

The danger of these assumptions

To assume that none of these problems exist is idealism. If you make these assumptions, you will shipwreck.
To assume you can safely operate Scrum when multiple of those problems exist, you're also going to shipwreck.
To assume that attending a Scrum training course equips you to take on this gorilla is also going to shipwreck.

To assume that Scrum has a solution to any these problems is false hope or snake oil, depending on perspective. Scrum assumes that they have already been solved - or at least, that you well know how to solve them. Scrum tackles none of them.

What if not

The Scrum Guide has no guidance on any of these topics, as all of these problems are assumed to be manageable and/or solved in a Scrum context.

Where these problems are significant, Scrum isn't the droid you're looking for.

Health Radars are institutional waste!

There's a recent trend that organizations transitioning to agile ways of working get bombarded with so-called "health checks" - long questionnaires asking many questions, that need to be filled in by hundreds or maybe even thousands of people in short cycles. They deprive organizations of thousands of hours of productivity, for little return on this invest. 

Radar tools are considered useful by consultants with little understanding of actual agility. 
My take is that such tools are absolute overkill. What you can do - to save time and effort, and get better outcomes.

The problems of health radar tools

Health radars are deceptive and overcomplicate a rather simple matter. They also focus on the wrong goal.

A radar is only helpful when things are happening outside where you could otherwise see them.

If an organization wants to be agile, the goal should be to improve line of sight, not to institutionalize processes which make you comfortable with poor visibility.

The need for a radar reveals a disconnect between coaches/managers and the organizational reality.

Early transition radars

When an organization doesn't understand much about agile culture and engineering practice, you don't need a health radar to realize that this isn't where you want to be: time-to-market sucks, quality sucks, customer satisfaction sucks, morale sucks. No tool required.

Initial health radar surveys usually suffer from multiple issues:

• Culture: Many traditional enterprises are set up in a way that talking about problems isn't encouraged. The health radar results often look better than reality.
• Dunning-Kruger effect: people overestimate their current understanding and ability, as such, overrate it.
• Anchoring bias: the presented information is considered far more reliable for decision making than it is.

I don't think it needs much further explanation why taking a health radar under these conditions can actually be a threat, rather than a help.

Repeat surveys

The next problem with health radars is that they are usually taken in cyclical intervals, usually ranging from monthly to quarterly. Aside from people starting to get bored having to answer the same fifty questions every month (oddly enough, agile development would encourage automating or entirely eliminating recurrent activity!).

Frequently repeating the surveys thus suffers from:

1. Disconnect between change and data: Especially in slow-moving environments, the amount of systemic change that warrants re-examination of the state tends to be low, so the amount of difference over time that can actually be attributed to actual change in the system is low. 
2. Insignificant deltas: Most change actions are point-based optimizations. Re-collecting full sets of data will yield changes that are statistically insignificant in the big picture.
3. Fatalism: When people see that there are dozens of important topics to be changed, and that progress is really slow, they might lose hope and be less inclined to make changes.
4. Check-the-box errors: With increasing frequency of surveys, more and more people will just check some boxes to be done with it. The obtained data is statistically worthless. It might even require additional effort to filter out. Likewise, the consequently reduced sample size reduces the accuracy of the remaining data.

Those are the key points why I believe that constantly bombarding an entire organization with health radars can actually be counterproductive.

A much simpler alternative

With these four rather simple questions, you can get a clear and strong understanding about how well a team or organization is actually doing:

Sometimes, those questions don't even need to be asked. They can be observed, and you can enter the conversation by addressing the point right away.

The four questions

To the observant coach, the four questions touch four different domains. If all four of these domains are fine, this begs the question: "What do you even want to change - and why?" - and taking a Health Radar survey under these conditions would not yield much insight, either.

Usually, however, the four questions are not okay, and you can enter into a conversation right away.

1 - Product Evolution

The first question is focused on how fast the product evolves.

If the answer is "Quarterly" or slower - you are not agile. Period.

Even "daily" may be too slow, depending on the domain. If you see inadequate evolution rates, that's what you have to improve. 

And don't get misled - it may not be the tool or process: it may be the organizational structure that slows down evolution!

2 - User attitude

The second question is focused on users.

If the answer is, "We don't even know who they are" - you are not agile. Period.

Some teams invite selected users to Reviews, although even this can be deceptive - having an informal chat with a real user outside a meeting can be revealing indeed.

3 - Developer attitude

The third question is focused on members of the development organization.

If the answer is anywhere along the lines of "I'm looking for job offers" - you are not agile. Period.

Sustainable development can only be achieved when developers care about what they do, are happy about what they do and willing to take the feedback they receive.

4 - Continuous Improvement

The fourth question is focused on how improvement takes place.

If the answer is along the lines of "We can't do anything about it" - you are not agile. Period.

People need to see both the big picture and how they affect it. The system wouldn't be what it is without the people in it. The bigger people's drive to make a positive impact, the more likely the most important problems will get solved.

The core of the matter is what people do when nobody tells them what to do. Until people have an intrinsic drive to do the right thing, you're not going anywhere.

The conversation

Depending where you see the biggest problem, have a conversation about "Why": "Why are things the way they are?" - "Why are we content with our current situation?"- "Why aren't we doing better?" - "why do we even want to be agile if we're not doing our best to make progress here?"

People can have an infinite amount of reasons, so this is the perfect time to get NEAR the team and their stakeholders.

Following up

The followup set of questions after a prolonged period can be a series of "What" questions: "What's different now?" - "What have we learned?" - "What now?"

Summary

Drop the long questionnaires. They waste time, capacity and money. 

Learn to observe, start to ask questions. Reduce distance in the organization.

You don't need many questions to figure out what the biggest problem is - and most of all, you don't need to "carpet bomb" the organization with survey forms.  Keep it simple.

Often, people know very well what the problems are and why they have them. They just never took the time to get things sorted. All you need to do is help them in understanding where they are and discovering ways forward.