Manifesting Business Agility

This is a chapter from my upcoming book Amplio@Teams: The Path to Effective Lean-Agile Teams.

What a coach is in the Agile community depends upon who you ask. I believe a coach is a change agent. While not tasked with telling people what to do, they are much more than a facilitator.

A Lean-Agile coach is a person who understands how to help teams and organizations improve with the theories of Flow, Lean, and Theory of Constraints while also understanding the basics of human learning. Coaches need to play an active role in helping teams improve. By ‘active,’ I don’t mean they tell people what to do, which doesn’t work. Many people believe this is because people will resist when told to do something. But that’s not true. Many times people want to be told what to do. But if you tell people what to do, they may do it without working through the details of what is involved. If they run into problems, they may not know what to do. This lack of understanding may have them abandon the suggestion.

Being an effective coach requires:

1. A deep understanding of the area in which you are coaching.
2. Being able to convey ideas to people 
3. Understanding how people learn.
4. Tools to help people work together.
5. The appropriate character

A deep understanding of the area you are coaching requires theory and practice. Deming said, “Experience teaches nothing. there is no experience to record without theory… Without theory, there is no learning… And that is their downfall. People copy examples and then wonder what the trouble is. They look at examples, and without theory, they learn nothing.” When a coach understands why things work, they can provide that understanding both to the people doing the work and those responsible for them. This helps get everyone on the same page.

Conveying ideas to people requires understanding their concerns. For example, many people talk to executives by saying we must not start too many projects but instead have a focus on finishing. But many executives will hear this as getting less value, not more. Instead, we must tell them we will focus on delivering value faster. Executives will appreciate value sooner than working on fewer things.

You must also understand how people learn. People are complex beings. They have limitations on how they can learn and how much they can know at any one time. Understanding these limitations can avoid a lot of wasted effort. Understanding how people learn can help avoid invoking resistance in people.

Coaches should look for virtual boards to help the people they are coaching learn together. Teams are often not co-located yet still need to work together. Virtual boards are essential for this.

Having the appropriate character is essential but is something coaches need to learn for themselves. If a person doesn’t have the right temperament, they may be smart, but they won’t be effective. They will come across as arrogant and gruff, and people will resist their suggestions even when recognized as experts.

People tend to go to extremes in the Agile space. The options are not about standing back or being overly pushy. When you understand what’s going on, you can ask questions that guide and enhance other people’s understanding. You can point things out that others don’t notice. Being a good coach requires this. It’s not an attitude of following (the guide) but one of leading others in learning.

Let me first acknowledge that I am not an expert in sensemaking in the academic sense. I am writing this as a practitioner/consultant in the knowledge work arena. Nothing in this article is intended to attend to domains outside of knowledge work although I am sure some of it does.

Weick, Sutcliffe and Obstfeld state that “Sensemaking involves turning circumstances into a situation that is comprehended explicitly in words and that serves as a springboard into action.”

Since knowledge work is done in a complex adaptive system, sensemaking is useful to better understand what often appears to be a chaotic, impenetrable situation. Systems thinking tells us that systems are more about the relationships between the systems than the components of the system. As Russ Ackoff points out, a collection of the best parts of the best cars is just a pile of junk. One way of thinking about this is not that we exist in different states, but that in knowledge work there is an integration of simple, complicated and complex relationships present.

These relationships have aspects that are simple, complicated and complex (meaning not understandable or even visible). Understanding how the parts of a system interact is consistent with what Dr. Eli Goldratt (creator of Theory of Constraints) describes in The Choice. He calls the essence of his approach ‘Inherent Simplicity.’ This is expressed in these quotes

Quotes by Dr. Eli Goldratt from The Choice:

“The first and most profound obstacle is that people believe that reality is complex, and therefore they are looking for sophisticated explanations for complicated solutions. Do you understand how devastating this is?”

”The biggest obstacle is that people grasp reality as complex when actually is surprisingly simple.”

“The key for thinking like a true scientist is the acceptance that any real-life situation, no matter how complex it initially looks, once understood, is actually embarrassingly simple. Moreover, if the situation is based on human interactions, you probably already have enough knowledge to begin with.”

“Inherent Simplicity. In a nutshell, it is at the foundation of all modern science as put by Newton: ‘nature is exceedingly simple and harmonious with itself.’”

"If we dive deep enough, we’ll find that there are very few elements at the base - the root causes - which through cause and effect connections are governing the whole system.”

The question, of course, is what are these “very few elements at the base?” Observations of both successful and failed attempts to improve an organization’s ability to deliver value to stakeholders has led me to the conclusion that there nine of these. I call these “vectors for effectiveness.” They are, in a sense, dimensions to observe how to improve an organization. They are consistent with the natural laws of knowledge work. They are:

1. Value stream management
2. Working on small items of high value
3. Queues, task switching, delays, handbacks (measure of workflow efficiency)
4. Making work and workflow visible
5. Getting feedback quickly
6. Efficient value creation Structure
7. Independence of value streams
8. Good product quality and architecture

Effective organizations tend to do these well and ineffective ones can improve by attending to them.  

Because complexity (both inside and outside our organization) is ever present in knowledge work, we can never see exactly what is happening, nor can we make totally accurate predictions. However, if we don’t attend to the complicated causal relationships that are known via Flow, Lean and Theory of Constraints, our methods will almost certainly be out of control.

The approach I espouse then is to understand what we are predictably doing wrong. We look for the results of actions based on these factors and validate (or invalidate) them. This results in movement forward or learning by exposing relationships we either didn’t see or didn’t understand due to their complexity. This enables us to move forward. It also suggests we take a skeptical view of these factors themselves. Always looking to refine our model for understanding.

It is also important to recognize that in knowledge work there is a particular type of waste that complexity enables. These are when a small error results in a big cost. These are called non-linear events. Non-linear events due to a combination of three things: 1) a small error, 2) lack of visibility to see what’s going on (often due to complexity), 3) coupling that results in a cascade of errors, resulting in a big error.  A great example of this in knowledge work is when a small misunderstanding of a stated requirement causes creating the wrong functionality in a big program that makes it useless. Or a “one-off” error in code causes a catastrophic error.

The bottom line is that sensemaking should be used as a basis for taking effective action. By using inherent simplicity and the factors for effectiveness I’ve identified, you can both better see what’s going on as well as having these observations be directly related to actions you can take to improve the situation. 

If you are interested in learning more about how to apply these check out my workshops (including the Disciplined Agile Value Stream Consultant) and collaborative engagements see the Success Engineering website. 

Although I'm no longer in the PMI, I still have great respect for its products and membership. I joined the PMI a couple of years ago for several reasons. One of the biggest was the clear desire of most PMI members to want to learn. I know many PMIers wondering about what their next steps should be. Agile is decidedly more than a fad, so that makes it more attractive. But it also seems to be anti-management and a bit free-wheeling as well - which goes against many of the principles and philosophies we've seen useful.

 In thinking about this, I believe the choice forward for many PMPs and other PMI members is a combination of the Disciplined Agile Value Stream Consultant workshops as well as some of the new work I am doing with Success Engineering. I'll talk about why the Disciplined Agile Value Stream Consultant workshop in this post. In the next few days I'll follow up with my new efforts with Success Engineering. These products won't be available until early next year.

 What makes the DAVSC appealing to PMPs.

While I have been a believer in Agile from before it began, I have always been troubled by a few things. These are mostly its:

• Team-centricity
• Anti-management attitude
• Lack of discipline
• Missing a scientific model that explains why it works

 I created the DAVSC as a way to teach consultants how to:

• look at the entire value stream
• include management in the Agile transformation process
• provide clarity on essential practices and why they must be done
• Understand a scientific model that explains why Agile works and what to do when you venture into new ground

 In a nutshell, it teaches participants how to guide transformations in a manner I found was effective for both me and other top consultants.  I created on the basis of what successful consultants needed to know by observing them (and not so success consultants) for almost 2 decades.

The DAVSC is more focused on teaching you how to think to solve you and your clients' problems than how to adopt someone else's solutions.

I'm co-teaching 3 Disciplined Agile Value Stream Consultant workshops over the next 6 weeks in different times zones. You can see them here.

Each session will be followed by a 45 minute session for additional Q&A that will also include why and how the workshop was created. Although you currently need a DASSM certification to be certified in the workshop, you are more than welcome to attend if you believe that the general concept of Agile is a good one.

 Feel free to contact me for more information

 Al Shalloway

Complexity has become a big topic in the Agile space. I don't agree with much of the conversations about it and thought I'd post a collection of the posts I've made on linkedin here.

The main guide I use in navigating complex systems in knowledge work is starting with the idea that all of our systems are complex. People are involved and we're doing things we've never done before. As a systems thinking all parts of the system typically have aspects that are simple, complicated and complex. I believe the biggest danger is from chaotic events which can be mitigated with quick feedback, decoupling of events and visibility.

I then navigate with Dr Goldratt's Inherent Simplicity. I've made a list of aspects of the value stream which is useful to look at. https://bit.ly/3lOvdUX

I present this before my posts because it creates a context for learning.

Here are my other posts. These were written over the last 2-3 years with the most recent ones first.

There is cause and effect if you know what to look for. https://lnkd.in/g5yJaKfm

In defense of root cause analysis  https://bit.ly/2Ry37Eo

Unless you believe in magic, there is cause and effect in complex systems https://lnkd.in/gXcRJUWX

Cause and Effects to Look For and How to Use Them https://bit.ly/2YX1aB6

What Causes our Problems      https://bit.ly/3lYS7sw

Attending to Cause and Effect in Complex systems     https://bit.ly/39dThO1

In Defense of Cause and Effect     https://lnkd.in/g9ik37gu

Cause and Effect in a VUCA World -making things worse   https://bit.ly/3qx8wYl

Let’s not throw out our ability to see cause and effect with the complexity bathwater https://bit.ly/32W5Rx4

Cause and Effect Does Exist in Complex Adaptive Systems   https://lnkd.in/gsEmeHmt

There is cause and effect between actions and results   https://lnkd.in/gFQnK6-s

Many people tend to look at scope, time and cost as 3 factors for completing a project and that all 3 can't be set. This is the trouble with fixed scope, time & cost projects. Waterfall projects often fix all 3 with at one of these factors being missed. That is, scope is dropped, project is late, and/or we have cost overruns.

Agile attempts to have these work more effectively by fixing time & cost with time-boxing. This is the essence of a Scrum sprint. This is an improvement. The most important work can be accomplished & smaller cycles are a major improvement.

But this line of thinking still has the 3 in conflict with each other. Lean suggests that "scope" is more complex than just "what to do." That we need to focus on actual value delivered, not merely what work is being done. Lean-thinking tells us that our work is composed of work of value (some more valuable than others) as well as waste. This waste is due to rework & working on the wrong items. Instead of being locked into the iron triangle (flipped or otherwise) we want to focus on eliminating this waste.

Most waste is due to delays in workflow and in feedback caused by poor workflows and teams being overloaded. Handoffs, handbacks, mis-communications and more are rampant. Lean-thinking tells us that scope, time and cost are not necessarily opposed to each other but that two other factors need to be attended to - product quality and workflow quality.

Attending to these five factors enable more useful work to be done in less time and with less cost. This happens because as product quality increases, rework for building the wrong thing goes down. As workflow quality increases, rework due to delays in feedback go down. It is also useful to note that risk also goes down as these factors work together.

The issue isn’t to see how to best do trade offs. It’s to understand that these five aspects work together and that true value can be realized in less time. This is the heart of business agility – the ability to realize value quickly, sustainably, predictably and with high quality.

This doesn't, of course, mean schedules don't matter. But it facilitates us focusing on delivering the most important value in an efficient method.