The Agile transformation myth, a topic we will introduce in the Flow System Playbook (March 2023), suggests that applying a universal framework will magically transform your organization, both operationally and culturally, into something that ensures faster delivery of value while creating a harmonious working culture previously unobtainable.
Organizations are spending extraordinary budgets on implementing a solution to an ill-defined problem, and pushing frameworks onto an ill-defined problem will almost always result in poor outcomes.
My advice – before you implement a solution, first define the problem you are trying to solve.
Key Takeaways
- Agile has value but is not a universal fix for your systemic problems.
- We tend to apply solutions without truly understanding the problem.
- Ill-defined problems will yield poor outcomes irrespective of the solution.
- You can’t optimize a system you don’t fully understand.
- Leaders need to engage at the point where the work is done.
- Not all constraints in a system are bottlenecks.
- Constraints are both inhibiting and enabling.
Remember: If you found this post useful and are not already a subscriber, sign up for the NEWSLETTER.
Q1: So what do you think the problem is?
I often ask this question to senior executives when they invite me in to talk about Agile Transformations. They look at me for a second and then respond with a list of problems. Revenue disappointing, profit down, costs too high, time to market too slow, projects delivering late, product quality below expectations, staff attrition and so on. The usual suspects. My reply? These are not problems, these are outcomes or results. They reflect how you do what you do. If you want different outcomes you need to change how you do what you do!
Q2: Do you know how you do what you do?
This seems like an obvious next question, but when I ask it to the same puzzled executives I get some standard responses about their great products and services, even though I am typically there to discuss delivery issues. I repeat my question with more emphasis.
What I’m driving at here is do they truly understand the end to end product or service flow that enables them to create value. Do they know what the people doing the work actually do? Until you understand how your products and services are delivered end-to-end, concept to cash, then how do you know what needs to be fixed? The only way to improve how you do what you do is to understand how you to what you do.
This is one reason Toyota leaders are grown over many years, working throughout the company learning how they do what they do, so when they get asked to improve how they do what they do, they know how to do that.
I talked about this topic in a video I made here about value stream mapping.
Q3: How do you think work gets done?
The way work gets done is often very different to how managers and leaders think it gets done. This simple illustration makes an important point. Often leaders in organizations are recruited into the company without prior experience actually doing the work, or like me they have done the work many years ago and their skills are now distant memories, or more likely the technology and processes have evolved to a point where their experience is less useful.
How can we as leaders implement/dictate improvement strategies if we don’t truly understand how those that are closest to the work actually do the work?
Going to the Genba!
I was recently called in as part of a team to help a food processing plant find ways to improve how they do what they do. I am NOT an expert in food processing! I spent 3 weeks filming the way the people did the work. I made many notes, wrote a bunch of calculations down, professed great wisdom in management sessions, drew lots of diagrams, and still I didn’t truly know how they do what they do.
Note: Genba (also spelled Gemba) means the “actual place” or the “real place” and it is the place where the actual work happens.
I then asked if I could try the work to see what it was like. I expected to have a quick go, maybe 15 minutes or so. The plant management team seized on this chance to “chuck the consultant on the line” and agreed as long as I would agree to spend a full shift, 8 hours, on the line! What was I going to do? Say no!? So of course I agreed and went and did the work! I am in the green hat.
Now, this is not feasible in all contexts, but it is what you need to to do if you truly want to improve how you do what you do. Talk to the people who do the work. Give them a psychologically safe way to express the improvements they might make, or the constraints they might eliminate. Walk in another man’s/woman’s shoes for a day.
This was the hardest days work I had done in at least two decades! I literally prayed for death every hour hoping I’d collapse and they’d carry me off on a stretcher! Those who do the hardest work are often those who get the least recognition, let alone the people we listen to the most, yet they know more than anyone managing from the office!
I learned more in 8 hours working with the people closest to the work than I had learned in 3 weeks of watching them do the work. If you truly want to understand how you do what you do, then you have to go and do what you do, or at least get as close to it as possible. If you can’t see it, you don’t know what you need to fix.
Toyota have known this for decades. It’s one of the reasons they are so successful.
Go and Observe, not just see!
One caveat: The purpose of “going to the genba” is NOT to “go see” it is to “go and understand and take action”. Many Lean practitioners extol the virtues of taking leaders to the genba to “go and see for themselves” but most of the time they go, see, and leave. They do nothing.
Sure, they may thank the workers and show some interest in what they are doing, but few ever listen, actively listen, and learn what needs to happen and then take appropriate action to make it happen. The true meaning of the Japanese phrase is “to understand the facts without assumption, where the issues actually occur, and to take the next action” or at least to enable action to be taken.
It’s not meant to be sightseeing!
A similar phrase “Genchi Kenbutsu” means to just “go and see”. It is translated as “sightseeing” and is akin to what many leaders and managers do. They go and see but do nothing. Maybe they ask for progress reports, or review some metrics, or worse, they ask for a PowerPoint deck!
Go and Observe. Understand though active listening. Take action or empower others to take action.
Understanding System Constraints
All systems have constraints. The Theory of Constraints from Eli Goldratt defines a constraints as “Anything that limits the system from a higher level of performance.” (Pretorius, 2014, p. 498)
The Theory of Constraints shows how any improvement before a bottleneck will actually make it worse, with work accumulating in front of it, while any optimization after the bottleneck will leave it starved for work. This is the balancing act needed when managing capacity and demand. As you start to understand the ‘how’ in how you do what you do, you will start to reveal the constraints in the system you need to address. Rarely are these going to be solved by “going Agile” or “doing Scrum”.
Constraints are limitations or restrictions that affect the behaviors of agents (people, technology, machines etc. in the system). Constraints are self-derived and cognitively constructed. Realizing what constraints are in place is essential for any team or organization in complex environments. Managing to remove unnecessary constraints is necessary for an organization to function effectively. Extract from The Flow Guide.
Not all constraints are bottlenecks.
A bottleneck is a resource with capacity less or equal to the demand put upon it, while a constraint is a limiting factor to the organization’s performance, an obstacle hindering the organization from achieving its goal. A constraint can be called a bottleneck if its capacity related, but a bottleneck is not always a constraint as the limiting factor may have nothing to do with capacity. Other examples of constraints include: legal, regulatory, financial, political, and bureaucratic process, the latter being the most common in my experience.
Inhibiting Constraints
While the theory of constraints differentiates between physical and non-physical constraints, it does not differentiate between the positive and negative connotations of a constraint. We view constraints as being either inhibiting (that represent the negative aspect of a constraint) or enabling (to represent the positive aspect of a constraint).
Constraints can be enabling or inhibiting. To enable and optimize flow in an organization, we need to limit the number of inhibiting constraints while optimizing enabling constraints. An enabling constraint allows an agent to operate with autonomous decision making, but within boundaries that are defined to prevent undesirable outcomes. An enabling constraint is value added. Directed, mandated, or required by regulatory agencies often impose inhibiting constraints. An inhibiting constraint typically has no value-added benefits. Extract from The Flow Guide.
Enabling Constraints
An enabling constraint allows an agent to operate with autonomous decision making, but within boundaries that are defined to prevent undesirable outcomes. An enabling constraint is value-added.
Summary
Before throwing solutions at a problem you need to understand what the problem is. What are the constraints in your system preventing the system from achieving a higher level of performance? Before you invest your valuable budgets in consultants to train and drill your people in the Agile dark arts and Scrum mastery you should first understand if the solution will solve the cause, or simply mask the symptoms temporarily. Agile has a place, but is not a panacea delivering universality, that desired one-size-fits-all framework. Don’t believe the hype.
In future posts I will cover in detail the topic of Value Stream Mapping that will help you “Learn to See” your constraints, and further understand how you do what you do.
