In slide #9 of this deck about using cycle time analytics in forecasting, Troy Magennis shows that when four people plan to meet for dinner, there is only one chance in 16 that all four will arrive on time. Typical corporate management thinking would solve this problem by creating a Department of Dinner Planning and promulgating detailed procedures, based on Industry Best Practices, to ensure people arrived on time for each dinner.
When that didn’t work (and it wouldn’t, of course), the typical response would be to tighten the screws. Make the procedures even more detailed. Limit the choice of restaurants to an approved list. Add bureaucracy to manage the approved list. Add some quality gates where work in progress can be inspected by accountable personnel. Punish the accountable personnel if they don’t find anything wrong, as something surely must be wrong. Increase the penalty for late arrival.
Other solutions become evident once we start to think outside the corporate box. For instance, we could duct-tape the four people together. Wherever they go, they go as one. That simple change increases the probability of on-time arrival from 1 in 16 to 1 in 2, an 8-fold improvement. What consultant wouldn’t be proud of an 8-fold improvement? Consultants call that sort of thing “low-hanging fruit.” I’ll bet we could get a client testimonial out of it, too.
Another possibility, and one that might appeal to Millennials, is to have dinner delivered to each person individually, and let them interact via social media. That imperfect solution still requires synchronous engagement and a degree of personal interaction, neither of which Millennials crave. Dinner 2.0 might include the ability to record and playback one’s participation in the event, represented by an AI-equipped avatar. That way, everyone eats when and what they please, without the burden of trying to hold up their end of a conversation. Each can play back the experience on demand, or just let the avatars get together in virtual reality and leave it at that. No need to venture out into meatspace at all.
If those solutions seem silly to you, then you may not be embracing corporate thinking fully. Remember that people are merely resources. Resources can be treated in any manner whatsoever, provided the end result comes out the way you want it to.
Just for grins, let’s pretend the four resources who are planning to meet for dinner are actual humans. How can they solve the problem of erratic arrival times?
One way I like to solve problems is not to solve them at all, but rather to change the parameters of the situation in such a way that the problem winks out of existence. In this case, we could agree to meet at a conveyor-belt restaurant. Dinner is served continuously, so it doesn’t matter exactly when each person arrives. No best practices, formal procedures, duct tape, or Departments of Dinner Planning are necessary. It’s definitionally impossible to arrive at the wrong time because there is no wrong time.
(Don’t be alarmed by that gentle tingling sensation in the back of your skull. It’s merely the firing of neurons that are associated with your understanding of continuous flow, small batches, and pull systems.)
Solution in Search of a Problem
What if it isn’t four people who want to meet for dinner. What if it’s four teams that contribute to the creation of a product. And what if “arrive on time” means “deliver your piece of the product when the teams that depend on you expect and need it.”
So we have the same pattern, but different details. Instead of people going to dinner, we have teams delivering subsets of a solution. There’s a 1 in 16 chance that all four teams will deliver on the planned schedule. How do we improve the odds? Typical corporate management thinking would solve this problem by creating a Department of Dinner…er, that is, a Program Management Office, or similar.
After creating unique and clever branding for their internal SharePoint site, the PMO would busily fail to coordinate the work of the four teams. Next step is to bring in outside consultants to implement an “agile framework” of some sort. Now they have four levels of PMO function, and 40 teams instead of 4. They hire 40 Product Owners and 40 Scrum Masters.
Things get worse instead of better. So they try harder. Maybe they aren’t using the framework well. Maybe they’re using it well enough, but they aren’t doing enough of it. Push, push, push. Grind, grind, grind. Stomp, stomp, stomp.
None of that helps, because management is attempting to solve a Thing That Is Not The Problem.
Structure, Governance, Metrics
After becoming acquainted with lean thinking, I started to notice things that I hadn’t really noticed before. Things about the effects of organizational structure, formal procedures, and technical practices on the results delivered to customers. I came to the conclusion that organizational structure has the greatest impact on effectiveness, procedures next, and practices last.
One of the things that attracted me to LeadingAgile was the emphasis on structure, governance, and metrics. Structure is just what it sounds like. Governance, in LeadingAgile parlance, isn’t about regulatory compliance; it’s an umbrella term for all sorts of process and procedures. It’s the governance of all your work. And metrics…well if you haven’t measured anything, then how can you possibly know whether you’ve improved anything?
Speaking of metrics, there’s one that I like quite well. It’s called process cycle efficiency. It’s the ratio of value-add time to total lead time. It’s interesting to figure this one out in IT organizations. Most people tend to guess their processes are 70% to 80% value-add and 20% to 30% waste. It turns out that process cycle efficiency is in the 1% to 2% range in most IT organizations. And if you examine the impact of cross-team dependencies, you’ll almost certainly find that it’s the single greatest cause of waste.
Most people in most IT organizations spend most of their time waiting for each other. Granted, they find ways to fill the time. Mostly, they fill the time by starting even more tasks that can’t be completed until they wait for someone else to do something, thus creating more waits. David Anderson of Kanban fame observed this years ago and coined the oft-quoted phrase, stop starting and start finishing!
Jim Benson, a noted thought leader in the lean space and the creator of Personal Kanban, captures a key idea: “Optimize when you can, standardize if you must.”
In contrast, conventional wisdom holds that we need to standardize as much as we can in the organization as a hedge against the unexpected and unplanned. This is important, you see, because anything unexpected or unplanned is Bad By Definition. It’s failure.
It’s that mode of thinking that leads to humans treated as resources, counterproductive emphasis on utilization over throughput, project thinking over product thinking, and heavy bureaucracy as an antidote to the natural consequences of ineffective organizational patterns.
If we organize teams around products or product lines rather than assembling teams on a per-project basis, we can reduce the interdependencies among teams and ensure each product is supported by people who possess all the necessary skills and have access to all the necessary resources to support the product properly.
We can do even better than that. We can organize people around value streams. A value stream comprises all the actions necessary to deliver some form of value to customers. In the IT field, a value stream may be a more expansive concept than any single product or product line. Sometimes, we can structure the organization like a conveyor-belt restaurant of value. (There’s that tingling sensation again.)
It isn’t difficult to gain agreement from organizational leaders about that idea, at least on a conceptual level. Why, then, do they persist in creating processes, procedures, and standards that restrict their ability to take full advantage of it?
On occasion I’ll ask people to play a little game. Assume there’s a flood. People are being washed downstream. Describe or draw how you would rescue them from the rushing water. People usually come up with something like this:
What happens in this scenario is that victims are slammed into the rope with the full force of the rushing water, quite likely knocked unconscious, and then they drown and/or get splattered by debris, such as automobiles and parts of buildings. They have a single, split-second opportunity to grab the rope, a feat which will require significant physical strength and exquisite timing under life-or-death pressure, when they’re probably already injured, exhausted, and terrified. The odds are very much against them.
When asked how to improve the plan, most people suggest using a stronger rope, or adding a second rope downstream. You know: Quality gates, PMOs, tight access restrictions regarding who can touch the rope or pull victims out of the water, etc.
The more formality, the more bureaucracy, the more layers of indirection, the better. The cynic in me wonders if they aren’t really interested in rescuing the victims, but just avoiding blame for those who drown. It’s the mentality behind the creation of “diversity programs” despite their well-known non-effectiveness, or the idea that no one ever gets fired for hiring IBM. We did something as opposed to nothing, so you can’t blame us.
But what if we wanted to do something effective, as opposed to just any old something?
Observing the way the universe appears to work, it seems we would want to “go with the flow” and use nature’s power to help us achieve the goal, rather than fighting against nature. Like this, perhaps:
What happens in this scenario is that people are carried downstream to the rope, which is stretched across the flowing water at an angle. They need not grasp the rope firmly but rather use it as a guide to reach the shore. They might just bump up against it repeatedly. The current pushes them downstream and the angled rope nudges them sideways. There’s a reasonable chance many will survive. If a car comes floating along it’s probably best to lift the rope out of the water to make room, or (worst case) let go of one end of the rope and throw it back across after the car passes.
This approach relies on the way things naturally tend to work, and allows everyone to adapt when unexpected things happen. It’s based on the unstated assumption that people are fundamentally good and will do the right thing if given the opportunity and the resources to do so.
Why is it that so many people can’t seem to imagine this approach, even when offered multiple chances to think of it?
Zen and the Second Law of Thermodynamics
I’ve found one answer in the work of Katherine Kirk, as expressed (for example) in her talk with Dan North at GOTO Chicago 2018 on SWARM: Scaling Without A Religious Methodology. As part of her ongoing attempt to figure out why things are the way they are, she looked into the philosophy of ancient Buddhist monks. They, too, wanted to understand why things are the way they are. Their approach was to observe the universe and make note of they way it appears to work. They figured that if we go with the flow of the way things naturally work, we’ll enjoy better outcomes than if we constantly bang our heads against reality in hopes of forcing it to be what we wish it were.
The monks noticed a few patterns. They observed that existence has three fundamental characteristics:
- Change – everything in the universe is in constant change
- Interdependency – we are always in some form of a system
- Dissatisfaction – people are uncomfortable with the uncertainty that results from change and interdependency
Katherine suggests we can take some lessons from this:
- Change drives the need to adapt
- Interdependency drives collaboration
- Dissatisfaction drives accepting feedback and iteration
Rather than governance designed to prevent or avoid change, we ought to come up with governance designed to adapt gracefully to change. Rather than organizing people and resources in a way that maximizes individual utilization, we ought to organize them in a way that maximizes collaboration. Rather than feeling frustrated that we can’t force the universe (or our company) to function in a manner contrary to Nature, we ought to use our discomfort about uncertainty to iterate over potential solutions based on feedback.
This may sound reasonable and it may be based on the way the universe really works, but it’s uncomfortable for many people nonetheless. Why? Well, people generally want answers, not more questions. This view of reality means our favorite Methodology or Framework can’t be the Final Answer Forever, that we can lock in and operate on autopilot. There is no Final Answer Forever, thanks to the #1 fundamental characteristic of existence: Constant change. Rather than a Final Answer Forever, what we need is a set of guidelines for adapting to change at scale.
If you’re not sure how to get started with this, I might know some people who can help.