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:

  • Continuously improve
  • Improve your understanding of your work
  • Know how to change a practice
  • Have frequent reviews
  • Use feedback to attend to risk

4.1 Objective: Continuously improve

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.

How to implement this when use timeboxing

The standard technique is to do retrospectives at the end of an iteration to see how to improve your work. However, doing them in the middle often works better since the team can then implement improvements during the iteration.

How to implement this when use flow

Do quick reviews of how queue management, product management and general working can be improved. Take one time on a regular basis to do a more in depth review.


Morale will decrease and your methods will get worse. If you aren’t improving you are falling backwards.


4.2 Objective: Improve your understanding of the way you work

It is important to understand why what you are doing is helping, or not. There is enough known now about universal principles to get good guidance from them. Without continuously improving on this understanding we’ll get complacent and stop making progress.

Why this is important

Our situations and problems change.  With a deeper understanding of what works and what doesn’t we can discover better practices to use.

How to implement this when using timeboxing or flow

Amplio Development is based on the concept that the most important thing we can do is learn continuously. This learning has many facets:

  • Are we building the right thing?
  • Are we building it the correct way?
  • Can the method we’re using to work together be improved?

We use quick feedback loops for the first two. The third can take advantage of the universal principles that we described earlier in the book.

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 Development if it will lead to an improvement. Even the universal principles it espouses are up for questioning. This is a marked difference between it and Scrum. While Scrum suggesting single-loop learning, it’s 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 the 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.

Use Plan-Do-Study-Act

Plan do study act 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.
  • Act on the study by both changing your model of understanding and seeing if you need to change your strategy for implementing this.

This is shown in figure 4.1

Figure 4.1: Plan-Do-Study-Act

Plan-Do-Study-Act 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 affects that your actions have. Lean suggests that one should consider how they are working to be the best way they know how. In this regards, their method of working is an 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.


The cost of not taking time to understand what we’re doing is that we take longer to find better solutions. If you find your team is facing the same problems over time you may not be working enough for a good understanding of what’s happening.

4.3 Know how to select a more appropriate practice

A fundamental assertion of Amplio Development 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 anytime. 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 problem? 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 make it worse, -1 means somewhat make it worse, 0 means no effect, 1 means somewhat make it better, 2 means significantly make 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 reducing 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?



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.

4.4 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.


Errors keep happening and things stay blocked.

4.5 Objective: Use feedback to attend to risk

There are many different types of risk. At the team level the most important ones to attend are:

  1. Risk of misunderstanding a requirement
  2. Risk of building the wrong thing
  3. Risk of creating bugs

We’ve already talked about some of these issues. Risk can often be planned for but the best way to attend to it is to continuously see if you’ve gone off track. This is why quick feedback is so important.

Why this is important

While it would be great if we could stop making mistakes the biggest cost is the waste emanating from them. This comes from the cost of mistakes propagating as well as the time (effort) it takes to fix them.  Both of these tend to increase over the time a mistake is made until it is detected (assuming it is). Therefore, detecting errors quickly is critical.

How to implement this when using flow

Quick feedback loops at all levels are important. When something is started it needs to be completed as soon as possible. This is true for all types and sizes of artifacts. Keeping the amount of work in process below our capacity is a way to assist in this.


Errors keep happening and things stay blocked.


Go to Amplio Development: The Path to Effective Lean Agile Teams 



Latest Article

Why Leaders Should Focus on Value Streams

Read on Cutter's site >>

Latest Presentation

Intro to BLAST and How To Solve Challenges in the Workflow

Watch Video >>

Upcoming Event

The Amplio Community of Practice (Free)

Learn More >>

New Workshop

The Amplio Development Masterclass

More Info >>

Latest Presentation

Intro to BLAST and How To Solve Challenges in the Workflow