Continuous Learning

Both Agile and Lean are primarily about learning. This is often not noticed but is the essence of both. Lean is about incrementally improving systems. Its “stop the line” mentality is based on the mindset that the system is causing almost all of the errors that occur. Therefore, when one is found we must fix it immediately or it will cause other errors. While many pay attention to the 4 values and 12 principles of the Manifesto for Agile Software development, its opening words “we are discovering better ways …” are most important.

This is not something to take place daily or weekly or at the end of an iteration. It is something to do continuously. Learning and improving is about what we’re building, how we are building and what our process is of building. These are the lessons in this chapter:

  • Look ahead and do a pre-mortem
  • Keep everyone informed
  • Swarm on problems
  • Know how to select a more appropriate practice
  • Have frequent reviews

The key here is “continuously.” Waiting for a time to improve has 3 serious consequences. First is the lost opportunity for improvement. Something noticed early doesn’t get improved for days or weeks. Second is that at the end of an iteration people want to either celebrate or forget what happened. The opportunity for improvement seems lost. Reflect on this for a little while and see if this explains why so many daily standups and end iteration retrospectives seem stale.  Third, sometimes the opportunity just doesn’t come. Learning is not something to leave for later, but something to do frequently.

There is a lot of evidence that people learn best by learning in small, frequent intervals. This also makes learning safer as we’re taking small, frequent steps. We want to build the habit of learning. A learning organization is one where the people in the organization learn habitually.

One thing we should be looking for is how to shorten the time of delays and reduce the number of handoffs.

Why this is important

Continuous learning is best. Having a model to adjust is also critical. Waiting until the end of an iteration somewhat demeans the importance of learning not to mention, it’s the least effective place to do it. Short reviews on a mostly continuous basis is ideal.

NOTE: the “guided” part refers to both being guided by a theory as well as options to choose from.

The underlying belief system

This paper discusses a different way to deal with complexity than suggesting complex systems are unknowable and that we therefore must see what happens and inspect and adapt in response. It acknowledges that complex systems are, by definition, not completely understood. However, by attending to the embedded parts of the system we can understand, we can make reasonably predictable improvements in the system as a whole. It furthermore suggests, that while we have no control over the complexity of what’s outside of us, by improving our own methods, we can pivot when black swan or other unpredictable events occur.

I want to be clear that this discussion is in the context of creating and offering services to customers of an organization, a complex endeavor. I am not talking about complexity as it relates to nuclear reactors. When attempting to improve a way of working, it is often a good idea to understand if the work being done is complex, complicated, or even simple. With knowledge work, it’s almost always a good idea to assume you’re dealing with complexity. But in reality, you can’t separate an organization into its component parts. This is an essential concept of systems thinking that everything relates to everything else within a system – even the system containing it. For example, thinking the act of an employee putting shoes into a box prior to shipping is simple ignores the fact that they might be mad at their employer at the moment and intentionally put the shoes in the wrong box.

The key difference in attitude is not in recognizing we have different states, but in what you do after you see you have complexity present in your workflows. The important question “do you believe you can be proactive in your actions and reduce waste by taking advantage of what you know from theories presented by Flow, Lean, and the Theory of Constraints and using feedback to manage what you don’t?” The first step in doing this is to identify and use foundational principles.

A foundational principle is a principle that stands on its own and applies virtually everywhere. For example, delays in the workflow will create waste. And having people work beyond their capacity will cause multitasking and delays in workflows. These can be used to create guidance, e.g., “keep workloads below capacity.” Some people call these “first or foundational principles.” We prefer the term “foundational” to remind us that they represent the foundation for guidance. Also, to remind us that we need to always be validating them and not take them for truth.

Systems thinking tells us to attend to the relationships between the components of a system. Some of these are clear. Some merely involve a few others so as to be understandable. But some are so interrelated as to not be understandable – hence complex.

People take two attitudes about this complexity. Some believe this makes using the causality we understand less useful. While others believe that we can still take proactive action with it. In “The Choice”, Eli Goldratt says “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?” He continues with ”The biggest obstacle is that people grasp reality as complex when actually is surprisingly simple.”

He is not referring to an understanding of what’s happening. After all, he was a physicist and certainly was aware of the complexity of nature. He’s referring to what it takes to control and learn about systems. In particular, while product development is complex you can drive it by attending to relationships you can understand and be prepared for things to happen from what you don’t see/understand. And when these occur, you learn more about the system and how to work within it.

This does not mean everything is predictable. Far from it. Non-linear events (an event where a small mistake causes a big result) cause a tremendous amount of problems. But we can manage those with quick feedback, which creates visibility on what is happening and unobscures the fog complexity causes. In the physical world, this is not possible. Three Mile Island was caused in large part by a lack of visibility of what was happening. That need not be the case in knowledge work.

The bottom line is we shift our focus from understanding the state of our system to seeing what actions we can take that increase its effectiveness. With this attitude, you also look to see what are the issues that matter. Instead of identifying, that we’re in chaos, we look to see how we can avoid the chaotic (non-linear) events that are driving us to it. In knowledge work, I have identified nine factors that provide guidance in making good decisions on how to improve your work. I call these the Value Stream Impedance Scorecards. This shift also has us look at how to make a cohesive set of practices around the value stream networks present. All of this enables organizations to be able to pivot quickly, so when events outside of the organization occur, they can respond quickly and efficiently.

What happens when you don’t take this attitude is made clear by observing Agile’s most popular frameworks – Scrum and SAFe. Scrum is based on its creators’ own values and principles, not foundational principles which are objective. You must follow them, or you won’t be doing Scrum. But they often don’t provide guidance on how to achieve them and aren’t appropriate in all situations. SAFe is a collection of practices that don’t fit cohesively because foundational principles are missing as well. Ironically, Scrum’s simplistic and SAFe’s overly complicated approaches stem from the same belief – the world is too complex to understand, so use the practices they give you to get where you want to be.

Recognizing this creates an opportunity to use foundational principles to improve both Scrum and SAFe. It’s not that either of these frameworks doesn’t provide value, it’s that they each have gaps that enable filling in the blanks in Scrum case and mostly simplifying SAFe in its case.

Learning Methods

Plan-Do-Study-Adjust

Use Plan-Do-Study-Adjust

Plan do study adjust means to:

  • Plan what you are going to do based on your understanding of what’s happening
  • Then do
  • Study the results. This includes questioning whether you understanding of what’s happening is accurate.
  • Adjust both our model of understanding and our strategy if needed.

This is shown in figure 5.1

Figure 5.1: Plan-Do-Study-Adjust

Plan-Do-Study-Adjust Vs Inspect and Adapt

PDSA is an example of double-loop learning. Each cycle includes questioning if we can improve our approach. Inspect and adapt has us look to see how we must respond to what happened. But it doesn’t have us question our approach.

There is a big philosophical difference here. PDSA reflects our belief that much of what we do has a clear cause and effect. Inspect and adapt has us act as if we can’t understand this causality. We’re not suggesting that the work we do is deterministic, but rather our actions have somewhat predictable consequences.

Lean takes a scientific approach. It believes you can understand the effects that your actions have. Lean suggests that one should consider how they are working to be the best way they know-how. In this regard, their method of working is a hypothesis – “this is the best way to do our work.” We make improvements to how we work by suggesting new a new hypothesis and seeing what happens. That is, we see how our actions affected our results. In Kanban, we focus on managing work-in-process levels. Our process hypothesis typically includes a set of limits of different types of work plus service level agreements. We adjust these to maximize value delivered to the customer.

Observe-Oriented-Decide-Act

Use double-loop learning

Chris Argyris (1923 – 2013) clarified that there are two levels to learning, which he described as single-loop learning and double-loop learning.

Here are his definitions:

  • Single-loop learning: Learning that changes strategies of action (i.e. the how) …in ways that leave the values of a theory of action unchanged (i.e., the why)
  • Double-loop learning: Learning that results in a change in the values of theory-in-use (i.e., the why), as well as in its strategies and assumptions (i.e., the how).

In other words, single-loop learning has you change how you are trying to solve a problem but that doesn’t change the theory on which you are solving it. Double-loop learning has you change the theory (the why) and any assumptions underneath it.

There is nothing sacrosanct in Amplio@Teams if it will lead to an improvement. Even the first principles it espouses are up for questioning. This is a marked difference between it and Scrum. While Scrum suggests single-loop learning, its lack of theory as to how knowledge work requires you to stick with single-loop learning. From the Scrum Guide “Scrum is free and offered in this Guide. The Scrum framework, as outlined herein, is immutable. While implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety and functions well as a container for other techniques, methodologies, and practices.”

In the Agile space, you can think of “Inspect and Adapt” as single-loop learning in order to improve the process you are doing. For example, a sprint retrospective would have you look at how you could improve what you did in the last sprint. Double-loop learning would have you look at whether you should even be doing sprints. In other words, single-loop learning is questioning how to do your process better while double-loop learning questions the assumptions on which your process is based.

Continuous detection is a path to quick prevention

Detecting errors and impediments is important. But what’s better is preventing them. Early detection of errors with quick action to fix them leads to the prevention of these errors in the future. When one considers that most errors are caused by the system, this means that we can prevent a significant number of errors when we focus on early detection and correction.

This requires having a solid model of how things work, however. Fortunately, Flow, Lean, and the Theory of Constraints provide that.

It is tempting to be very specific at the front and leave the rest to the adopters. But we can’t be.

We need to prepare for the journey. Scrum is very specific on how to start. Makes it simple to understand. Scrum leaves how to improve up to its adopters. Makes it difficult to master.

The quicker you put in a correction, the quicker you prevent defects. Early detection is the same as defect prevention. If you move detection and correction up a certain amount of time, you prevent the errors over that time.

The value stream impedance scorecard can be used to detect errors in our workflow. Consider how each of them helps us in table 1.

  Value stream impedance vector Errors detected by it
1 Are small items of high value being worked on? Building something of little value is a kind of defect. By focusing on high-value items, we avoid this.
2 Are queues being managed to reduce delays and handbacks? Delays tend to create more misunderstandings
3 Are we getting quick feedback? By attending to feedback, we can course-correct and stop building the wrong thing.
4 Is the quality of the product high? (both behavior and how it’s built) Asking the question “how will I know when I’ve done that” avoids many misunderstandings
5 Are workloads of people within their capacity? When people are overloaded, they not only task-switch, but create more errors
6 Are all work and workflow visible? Lack of visibility often causes scheduling defects
7 Are people organized in a way that reduces waiting for others and handoffs? Poor organization results in more handoffs and therefore misunderstandings
8 Are development teams primarily working in one value stream? This helps avoid a lot of the problems above
9 Are people attending to the value streams? This helps implement a lot of the things above

 

5.1 Objective: Look ahead and do a pre-mortem

tbd

5.2 Objective: Keep everyone informed

tbd

5.3 Objective: Swarm on Problems

tbd

5.4 Objective: Know how to select a more appropriate practice

A fundamental assertion of Amplio@Teams is that there are no universal practices. We’ve used this to help decide which practice to use for a particular situation. This starting attitude can also be used to adjust the current set of practices we have if later we see we’re having challenges with one of them.

The idea is not to merely change practices when there are challenges, but rather to improve the practices we use as our understanding improves.

Why this is important

Using practices that are not well-suited to our situation has many disadvantages. First, we’re not working as well as we can. But just as importantly the team will get frustrated and stop trying to improve. The idea of “do this until you understand and then you can change” is disrespectful as well. Understanding should being with doing.

How to implement this when using timeboxing or flow

Making changes to practices can be done at any time. Whether you are doing timeboxing or flow does not matter. In both cases, you should have scheduled times to reflect on what you are doing. When using iterations there is a tendency to only reflect at the end of the iteration – this often creates a lost opportunity for improvement.

How to improve your practices

Here’s a process to use when you are having a challenge with a practice:

Step 1: Ask if you having challenges with the practice because it is being done poorly? If Yes, then consider how you can do it better. If No, continue.

Step 2: Is there something outside of the team that is causing us this problem? If Yes, then see how to fix that or at least influence the fixing of it. If No, then continue.

Step 3: Is the team in an ecosystem that is causing problems? That is, are people not collocated when they need to be or are required skills missing? Can you improve on this? If yes, do so. If No, continue to see if another practice that works within this ecosystem will work better (see next step).

Step 4: What else can we do that meets the same objective of the practice? If there is something else you can do, then try that. If not stick with the practice until you learn more.

How to tell if a change is better

Look at the current practice you are doing. Consider another practice to switch to which supports achieving the same objective. Which of these two practices best achieves the objective?

Use the following template to help you determine this:

Current practice _____________________________________

Alternative practice __________________________________

On a scale of -2 to +2 indicate how each practice would affect the value stream impedance scorecard.  -2 means significantly making it worse, -1 means somewhat making it worse, 0 means no effect, 1 means somewhat making it better, and 2 means significantly making it better.

Value stream impedance scorecard #1 #2
1. Does the practice attend to the whole or will it just provide a local optimization?    
2. Does the practice have us work on smaller, high value items?    
3. Will the practice reduce delays handoffs?    
4. Does the practice make work and workflow more visible?    
5. Does the practice change how people are organized so as to reduce waiting for others and/or reduce handoffs?    
6. Does this practice speed up getting feedback?    
7. Does the practice speed    
8. Does the practice reduce the number of value streams people are in?    
9. Does the practice improve the quality of the product to the customer?    
10. Does the practice improve the quality of how the product is built?    

Anti-patterns

Not attending to the value stream impedance scorecard has teams continue to use practices that are not well-suited for them. Look for the team not using the practices they agreed to because there is a sense they are not getting value from them.

5.5 Objective: Have frequent reviews

Have a way of course-correcting both what we are building and the way we are working. These go well beyond mentioning any blockages but look to see why they are there as well.

Why this is important

It is important to identify problems and solve them as soon as possible. Waiting until the end of an iteration is an incredible risk and waste. When challenges occur or mistakes are made, and they aren’t corrected quickly it tends to inure the team to just working through problems.

This is the equivalent to Lean’s “stop the line” attitude. When a problem occurs, fix it immediately.

How to implement this when using flow

There are two main ways to implement this. The most common way is to have daily standups. Standups should be done by focusing on the work. A common approach is to walk the work on the board and ask:

  1. This is what we’ve done – and have a quick statement as to what worked
  2. This is what we’re going to do next
  3. This is what we’re having troubles with

Depending on the trouble one runs into, the team needs to look to see not just what the impediment is but what’s the cause of it. Is it how work is being done or what work is being done?

Daily standups can be enhanced or even replaced by impromptu meetings when issues come up. This second way requires a high degree of discipline, however.

Anti-patterns

Errors keep happening and things stay blocked.

Side notes

Empiricism confirms or denies the past. Theory provides a path to the future.

 

Go to Amplio@Teams: The Path to Effective Lean-Agile Teams

Go to Being a Professional Coach

New Workshop

More Info >>

Upcoming Events

None