This is a chapter from Amplio Development: The Path to Effective Lean-Agile Teams

This section presents the mindset, or underlying belief system, of Amplio, of which Amplio Development is a subset. This mindset is fundamental to all Amplio curricula, not just to Amplio Development.

A Fundamental Question that Separates Many in the Agile Community

A fundamental belief separates those proposing different “Agile” approaches. Many believe it is impossible to have a well-defined approach effectively solve complex problems. Underneath this is the idea that in complex situations, cause and effect cannot be seen except in hindsight. It results in an approach where we look for impediments and then use “inspect and adapt” to remove them. We try experiments and see what happens.

Amplio, on the other hand, is based on the belief that while complexity can obscure what is happening, understanding is possible. That we can discover a set of principles that provides us with a model of understanding and enables us to take actions that either provide us with improvement or a deeper understanding of what is happening. Furthermore, this “model” enables us to create new practices consistent with the model and for which we expect them to be useful. Instead of running experiments, we come from established theory and improve our workflow based on it. Of course, we have to validate that improvement has occurred. When it doesn’t, it is almost always the case that we’ve learned something in our situation.

In knowledge work, we can create visibility via feedback and decouple events to avoid non-linearity in our workflow. While discovering what to build may be complex, our approach to it doesn’t need to be.

The following sections give an overview of such a model

Systems Thinking and Complexity

“Today’s problems come from yesterday’s ‘solutions’.” 5th Discipline, Peter Senge.

Systems thinking is the foundation of Flow, Lean, and the Theory of Constraints. The essence of systems thinking is that a system is not merely the sum of its components but rather reflects the relationship between them. For example, a car is not merely a collection of tires, an engine, transmission, etc., on a chassis but rather the relationship between these.

Consider taking the best parts of the best cars and putting them together. You wouldn’t have a car – you’d have a pile of junk. Car-ness results from how the parts of a car work together.

There are a few other critical concepts involved here. A change to one part of a system can affect other parts. But not just one on one. It can affect how other parts of the system affect even other parts.  Sometimes these interactions are clear. Sometimes they are not. While we can understand these interactions with cars, in other systems, we cannot. We call these complex interactions. The presence of these interactions is why many systems are complex. It is often impossible to tell what change one aspect of a system will have with all the interrelationships present.

Systems can be thought of as a combination of known, well-defined relationships and those that involve complex interactions.  Amplio Development will directly discuss improving knowledge work by attending to the known, well-defined relationships. It will deal with the complex interactions by showing how quick feedback cycles can mitigate challenges arising from the non-linear events during development. Non-linear events are when a small action results in a significant impact. The “straw that broke the camel’s back” is an iconic example. While we often hear of disasters occurring due to complexity, we have more control over what is happening in knowledge work. This enables us to decouple the effect of complex events and avoid disaster or wasted effort.

A very salient aspect of systems thinking is that the system people are in causes almost all the errors and waste. It’s easy to attribute bad behavior to individuals, but it’s more likely that the system they are in is causing the problems.

An important distinction

Creating new products is an emergent process. It requires adaptation, and we must acknowledge the lack of predictability. But this does not mean that our work methods can’t be well defined.

Essential Lessons of Systems Thinking:

  • Systems are more about the relationships between their components than the components themselves
  • Systems are comprised of other systems and interact with systems outside of themselves
  • Local changes to a system cause global, sometimes unpredictable, side effects.
  • Most of the challenges we encounter are due to our system.

Systems Thinking in Knowledge work

In systems thinking we must look at all aspects of knowledge work. This means we look at the people, the customers, the other stakeholders, management, and the workflow. Everything.  One aspect is not more important than the other because all of these are intertwined with each other. This has often been ignored in the Agile community. In Amplio it may appear that we are over-emphasizing the mechanics of production. In fact, Amplio is merely trying to create a balance between all of these factors. One is not over another. Any failure in one will likely bring down the system as a whole.

Attend to Value Streams

What are value streams?

Value streams refer to the steps required from start to finish to accomplish something. There are many different types of value streams, but all have the main concepts in common. Value streams shift the focus from the people doing the work to the work being done, both its sequence and timing. There are many different ways of classifying value steams. For our purposes, we’ll classify them as:

  1. customer value streams
  2. value-enabling value streams
  3. operational value streams
  4. development value stream networks

Customer value streams are the value streams of the customer. Innovation is primarily about improving these value streams. They are primarily about using the product/service, getting support for the product/service, and setting up to get (or actually getting) the product/service.

Operational value streams. are those workflows for marketing, selling, deploying the product/service, and supporting customers.

Business-enabling value streams are the workflows for the internal process of the company. These activities include buying and maintaining a server network, stocking shelves, HR, and Legal.

Development value streams are the value streams creating the ones just mentioned. However, they are not linear as the others are and are better thought of as value stream networks. But the concepts and what to look for in them are very similar.

The Benefits of Attending to Value streams

“Attending to value streams” means:

  • being aware of them
  • notice how they interact with each other
  • when making a change, see how it will affect the overall productivity in the value stream

Consider how Apple changed how many of us listen to music. The iPod and its supporting music services changed the way people listened to music. By creating products and the systems people used, customer value streams changed. Breakthrough innovation usually comes from providing value to the customer by attending to how they work and designing our systems to influence that positively.

In most organizations people are busy, but the work often moves at a snail’s pace because it is continually stopping and starting. By attending to the value streams, we can see what is happening and how to improve it. This also highlights system constraints across all of the value streams mentioned.

Attending to value streams guides us in improving our development work while lowering its costs.

This book is primarily about the development value stream network that the team is embedded in. We will learn to work on smaller items, focus on removing delays, avoid overloading people in the value streams, and get people to be in one value stream to avoid multi-tasking. Flow, Lean, and the Theory of Constraints all attend to the value stream for several reasons. Mapping value stream networks:

  1. provide visibility on what is being worked on and how
  2. illuminates the delays in value add. These delays also create waste in the process
  3. illuminates the constraints in the system

Additional Resource: Why Leaders Should Focus on Value Streams


An Inherent Problem

Most organizations are organized in hierarchies to manage the work. But the workflows across the organization. This has us manage one way while increasing the value delivery requires us to manage another way.

Managing within a hierarchy

Hierarchies tend to have those responsible for the hierarchy see if the people under them are:

  1. working on the right things
  2. working well
  3. fully occupied

This seems so natural we don’t even think about it. But it also means the focus is on the silo, not across the workflow. This results in delays when handoffs are made between the siloes. Cooperation between the siloes typically takes second priority to the flow between the siloes.

Reflect for a moment on projects you’ve seen in the past. Let’s look at both the people doing the work and the work itself (when it is being worked on and when it is waiting to be worked on). See if what you notice matches the following table. Feel free to add to it

Watching the peopleWatching the workflow
·   people are busy

·   they are multi-tasking mostly because they are both interrupted and have to wait for others

·   their focus is on their work

·   people are measured on how busy they are, not on how much overall value is being done

·   the work starts and stops

·   work items spend time in queues

·   no one is managing the work itself

·   work is tracked where it is, but how much time work spends waiting is not tracked


When we look at the people doing the work, we focus on local steps in the workflow. This is the most significant difference between waterfall and Flow/Lean. In waterfall, we try to maximize the efficiency of the work at each step. The presupposition is that we can do this. Flow and Lean have us look at how long it takes to go from concept to consumption. Because people are busy and working on many things, a project that would take one month if all the people working on it worked on just it can easily take six months to accomplish when they are busy working on other things.

The actual cost of multi-tasking.

Many people point to multi-tasking as a significant problem. It is a significant one, but not the key one. Consider the cause of multi-tasking – people working in multiple value streams. People are being interrupted and are interrupting others. Correlated with multi-tasking is work waiting in queues. While multi-tasking may cause a 10-20% drop in efficiency, work waiting in queues can create unplanned work in the form of bugs, working on the wrong things, rework, etc., that is much larger.

Focus on delays – not eliminating waste

A common Lean mantra is “eliminate waste.” The problem is that mantra comes from looking at manufacturing. In this context, you can see waste. A car is being built, and errors are visible. Planning can be considered waste because you already know what to do. In knowledge work, the situation is different. First, you can see everything. You often don’t know when you have an error or not. Also, things like design and planning are not wasteful. Overdesign and planning are, but these are still necessary functions. On the other hand, re-doing requirements, working from old ones, building unneeded features, fixing bugs, overbuilding frameworks, duplicating components, and integration errors are wasteful.

These wasteful activities create delays in getting the information and using it or in the time of making an error and detecting it. This is yet another reason for quick feedback and reduced delays. The mantra needs to change from “eliminate waste” to “eliminate delays in the workflow.”

Getting executives to understand the value of quick flow

Here’s a way to get executives to understand the value of focusing on shortening delivery time. Let’s pretend we have an enhancement to a very important product to your company that took six months to build but would have taken only two months if the people working on it had focused on it. Imagine you asked one of your top executives: “would it have been worth paying 20% more to get this enhancement out the door in two months instead of six?” He’d almost certainly say “sure.” But now ask yourself, how would you get to do it in two months instead of six? You’d have to cut down the delays between steps. Doing so might require adding a little slack to the system, but other than that, removing delay is more likely to reduce unplanned work. In other words, instead of taking longer to reduce the build time to deployment, it’d take less time to get it out the door.

This shows another shift that’s needed: stop focusing on the utilization of people and focus on removing delays in the workflow.

What Analyzing the Inherent Problem Teaches Us

  • We must shift our focus from people doing the work to the work being done.
  • We shouldn’t manage hierarchies; we should manage the value stream.
  • We shouldn’t try to go faster; we should focus on eliminating delays by having fewer and smaller queues.
  • To align people around the value to be realized.
  • To shift from focusing on people’s utilization to removing workflow delays.
  • To stop striving for local optimizations but attend to the throughput of the value stream.

Why this shift is so necessary

The shifts above will enable us to focus directly on the work. This is more effective and will avoid making people defensive of their work.

Consultant’s Corner

Value streams are not business processes.

There is a difference between value streams and business processes. While there are some similarities, the differences are significant. Especially when going into an organization that thinks they understand their value streams because they have documented their business processes.

One significant difference is that business processes are what you are suggesting to do. Value streams are what is happening.

There is much value being lost by conflating these two good, concepts. This post points out some of the differences. One difference is merely focus. A shift from process to flow of creating value. Value streams are based on lean thinking – business processes stand alone. The context of lean thinking creates a focus on time and value. This reflects the importance of attending to Edgar Shein’s observation that “We don’t think and talk about what we see, we see what we are able to think and talk about.”

Here are some specific differences:

  1. value stream mapping is used to untangle value streams – that is, not have them cross each other – in particular, are people in the same value
  2. value stream mapping can be used to improve the value creation structure of an organization
  3. value stream mapping pays particular attention to the delays in workflow and feedback
  4. value stream mapping shows what is. You can also create a future value stream map to create guidance for improvement.
  5. value stream mapping is useful to identify the constraint in the workflow
  6. value streams nave an integrated way of identifying if a change will be an improvement to the workflow (i.e., the value stream impedance scorecard)

It may be that business processes can be modified to include this but I prefer an approach that inherently does it. We have seen too much of what is intentionally incomplete does – not many people fill in what should be present.

Additional Resource: Why Leaders Should Focus on Value Streams

First Principles, Mindsets/Values

Experience teaches nothing. In fact, there is no experience to record without theory… Without theory, there is no learning… And that is their downfall. People copy examples, and then they wonder what is the trouble? They look at examples, and without theory, they learn nothing. W. Edwards Deming

First-principles are those principles that can’t be decomposed into other principles but stand on their own. They should apply universally or at a minimum, state the context in which they apply. The first principles stated here apply virtually everywhere in knowledge work. Flow, Lean, and the Theory of Constraints help understand the cause and effect present in knowledge work. Here are some fundamental principles:

  • Delays cause additional work to be done due to slow feedback and degradation of information
  • Too much work-in-process causes delays that cause waste
  • Handoffs cause loss of knowledge and information
  • People working on too many things will cause delays
  • Components of systems interact. Improving one aspect of a system may adversely affect others so that the overall system’s performance will worsen.

Underlying Mindset and Values

Our mindset and values filter what we notice. This is often called ‘cognitive bias.’ It is essential to continue questioning our mindset and ensure it’s helping us.

  • Take a systems thinking point of view.
  • Assume you are working in a complex system and attend to the symptoms of complexity (lack of visibility and potentially non-linear events)
  • Have an attitude of doing things just-in-time
  • Focus on the delivery of value to the customer
  • Continuously improve your mindset by using both double and triple-loop learning
  • Have a positive attitude towards management. If they are not cooperating, ask yourself what they do not see and then provide that to them. Notice how this requires improving their understanding.
  • Respect people
  • Those close to the work usually have the best understanding of what needs to be done
  • Have those close to the work make decisions, but provide them with the information they need to make good decisions
  • Attend to and mitigate risk
  • Use metrics to see if you are progressing in the right direction
  • Recognize that work is not complete until the customer has received value from it.
  • Make learning a habit


There are four main dimensions to effective workflows:

  1. what is being worked on
  2. how the teams are organized
  3. how the work is being done
  4. how much work is being done
  • Get clarity on what success means for you and your organization
  • Focus on value creation for your clients, staff, organization, and society
  • Focus on delivering high value quickly that is easily consumable
  • Attend to the quality of the product

Attend to the effectiveness and efficiency of your workflow

  • Use pull, manage queues, and have a focus on finishing
  • Work on small items of deliverable value
  • Have short feedback cycles at all levels of the work
  • Organize your people to eliminate delays and handoffs in the workflow
  • Start with a fit-for-purpose starting point

Leadership and Management

  • Have leadership provide clarity on the why of the organization
  • Have management work to create a great working environment for the people of the organization
  • have those close to the work make decisions and provide them with the information they need to make good decisions

Overall Guidance

  • Understand the customers’ value stream
  • Design a customer journey that improves their operational value stream
  • Align your efforts around improving your development value stream
  • Focus on value delivery with high quality. Then how your team works within that context.
  • Recognize that those parts of an item to be released that are not finished represent incomplete work. The more incomplete work that is present, the more risk present.
  • Look for ways to work with others
  • Work on small items of value
  • Minimize delays in the workflow by managing queues, focusing on finishing, and avoiding handoffs.
  • Organize people into teams to reduce handoffs within a team and between teams
  • View handbacks as symptoms of misunderstanding or as discovering a prior step was not done properly[1]
  • Attend to the constraints in the system. Don’t try to improve everything at once.
  • Focus on global improvement and be aware of local improvements that don’t attend to global improvements
  • After completing something, look to finish something else before starting something new.

[1] A handback is when one person hands some work to someone else and then later they come back and hand it back or ask questions about it. This shows up as work moving backward in the value stream.

A Note About Amplio’s Focus on Workflow and Systems

Theories of Flow and Lean suggest that we need to attend to the workflow across the organization, not just the people creating the value. This provides a holistic perspective that can shorten the time to market.  The Theory of Constraints is also consistent with attending to the workflow. Edwards Deming (the person the Japanese credit with bringing quality to Japanese manufacturing) provided evidence that 96% of errors were due to the systems people used – not so much the people themselves. While this evidence was for manufacturing systems, it also holds in knowledge work.

The focus on workflow instead of people is not a degradation of the importance of people. It is just the opposite. It is based on our trust in people, so we don’t need to manage them. Instead, we want to give them an effective, efficient, sustainable environment.

The Value Stream Impedance Scorecard


Making decisions on how to do our work is complex. We need a guide to help us see which of two or more options is better. One way to do this is to see what resistance, or impedance, is in the value stream that slows the creation of value. The value stream impedance scorecard (VSIS) indicates how well we are doing and whether a new way of working will be an improvement.


It is not always clear how to improve how we are working in complex systems. A guide that can help us make better decisions on whether a change to our way of working will be an improvement or not is helpful. The Value Stream Impedance Scorecard (VSIS) predicts whether a speculated action will improve the current situation. The decision is guided by taking actions that improve the vectors and avoiding actions that make them worse. The contention is that the more we abide by these vectors, the greater value we will achieve.

While suggested changes still need to be validated, with a deep understanding of the VSIS, we can make changes with high confidence they will be an improvement. Otherwise, we’ll be left to try things we have less than full confidence in. This often leads to stasis in our methods as people don’t like to fail. If an intended improvement doesn’t manifest itself, the issues we look at will provide us with learning.


Time for reflection

Consider when you were introduced to an organization where your immediate reaction was, “Wow, this place is cool. I can see why they get so much done!”

Now consider when you were introduced to an organization where your immediate reactions were, “Wow, this place is horrible. How do they get anything done?”

You are likely reacting to tacit knowledge –what you know but are not always consciously aware of knowing it. Consider what factors you are looking at. For example, are people talking to each other? How busy are they? See if any of these factors are present in both situations but pointed in different directions

Consider how consistent these tacit judgments are in different places. While each may appear different, there is a set of actions that should be taken that make places easier to work in. That value stream impedance scorecard is a suggested set.

The Value Stream Impedance Scorecard assesses how much resistance there is to identifying, creating, and realizing both business and customer value based on observing several factors. These factors relate to what work is being done, how it is being done, and how people are organized to accomplish it. Each factor is called a “vector” since vectors define a dimension and an amount.

The vectors for the Value Stream Impedance Scorecard are:

  • Are small items of high value being worked on?
  • Are queues being managed to reduce delays and handbacks?
  • Are we getting quick feedback?
  • Is the quality of the product high? (includes both behavior and how it’s built)
  • Are workloads of people within their capacity?
  • Are all work and workflow visible?
  • Are people organized in a way that reduces waiting for others and handoffs?
  • Are development teams primarily working in one value stream?
  • Are people attending to the value streams?

They are asked in the form of a question to see the direction of what helps (yes answers) and what hurts (no answers). The selection of these particular vectors is not sacrosanct. And, to be candid, they have changed a little over time. This set was selected based on the following factors:

  1. Is each vector clear, and can it lead directly to action that will lead to improvement?
  2. Does the set of vectors we choose to use provide us with enough information to make good decisions for almost all challenges faced by teams doing knowledge work?
  3. Is the number of vectors as small as possible?

In other words, are they of use while providing coverage and not being too complicated?

Most people find these vectors more easily understood if formulated as an action to do. The VSIS vectors formulated as actions to take are:

  • Build small items of high value.
  • Manage queues to reduce delays and handbacks in the workflow.
  • Get quick feedback.
  • Focus on high product quality – both from the stakeholders’ perception and from how the product was built.
  • Keep workloads within the capacity of the people doing the work.
  • Keep all work and workflow visible.
  • Organize people and have them make agreements on how they work in order to reduce waiting for others.
  • Have development teams work primarily on one value stream. Organize people who have to support multiple teams to work on as few value streams as possible while still remaining appropriately loaded.
  • Have people attend to the value stream.

A deeper “why” the Value Stream Impedance Scorecard is so important

Doing things poorly will slow us down. But consider that other things are taking place as well. For example, not getting quick feedback will create extra work for us since we’ll make a mistake and work on both the wrong things and in the wrong way. Therefore, attending to the VSIS can enable us to work without delays and not create a lot of extra work we don’t need to do. Therefore, attending to the VSIS enables us to eliminate the creation of waste.

 Key points

It is worth considering that there are two different types of waste. The first is work we didn’t need to do over planning.  The other is work we created that we now need to do but which didn’t need to be created in the first place—fixing bugs, for example.

The Vectors Work Together

It is essential to notice how the vectors work together. As you improve one, it either improves the others or makes it easier to improve them. For example, notice how working on small items will help us achieve quicker feedback. This is consistent with Dr. Eli Goldratt’s (creator of the Theory of Constraints) view that work principles are harmonious. He called this “inherent simplicity” in his daughter’s seminal book “The Choice”  and contends that complex problems are more straightforward than they look if one knows where to look.

The value stream impedance scorecard provides a holistic view by attending to different aspects of a system. This makes it very useful.

How we will use the value stream impedance scorecard

The VSIS will be used in two ways.  First, it will be used to help identify what we’re doing that is causing our problems. The second way it will be used will be to verify if a new practice being considered to replace a current one will be an improvement. If the change violates the VSIS, then we likely shouldn’t try it.

Examples of Each Vector

  1. Build in small increments of high value. You accomplish this by working on small items that will provide value in and of themselves or are small slices of functionality that will provide feedback. We’ll learn business artifacts that will assist with this later in this book.
  2. Manage queues and focus on finishing to reduce delays and handbacks in the workflow. Attend to the number of items waiting to be worked on. While you need enough items to be ready to be worked on, having too many causes delays in the workflow. One way to manage queues is to lower the overall number of things being worked on. One way to accomplish this is that when someone finishes something, they look to see what else they can finish instead of starting something new. Queues occur when work is handed off from one person to another. It is important that this handoff also be managed to avoid the work being handed back later.
  3. Get quick feedback. Communicate with product owners as often as practical. Build things in a way that enables quick feedback.
  4. Focus on high product quality – both from the stakeholders’ perception and from how the product was built. Get clear on what it means to achieve a requirement before working on it. Use the feedback when you complete anything to ensure you’re working on the proper functionality.
  5. Keep workloads within the capacity of the people doing the work. Avoid having people working on too many things. Don’t overschedule people with work. Allow people to “pull” work when ready instead of pushing work onto them.
  6. Keep all work and workflow visible. Have all the work being done visible. Also, have the agreements of how you are working be clear to everyone.
  7. Organize people and have them make agreements on how they work in order to reduce waiting for others. Cross-functional teams are one way of doing this when they are practical and achievable. Consider delays, handoffs, and handbacks to be symptoms of a poorly organized team structure.
  8. Have development teams work primarily on one value stream. Organize people who have to support multiple teams wo work on as few value streams as possible while still remaining appropriately loaded. When people do need to work in multiple value streams, manage what they work on with Kanban boards.
  9. Have people attend to the value stream. When making decisions look at the overall effect the action will have. Local optimizations rarely affect overall value add unless the action relieves a constraint.

The value stream impedance scorecard in three sentences

Build in small value increments (1), with few delays in the workflow (2) to get quick feedback (3) and high-quality products (4).

Achieve this by keeping all work visible (5), avoiding too much work-in-process (6), focusing people on one product (7), and having them work together to avoid delays in the workflow (8).

Continuously learn with value stream management (9).

Reflection on how the Value Stream Impedance Scorecard tells us if we’re following first principles.

While keeping the list of vectors of the value stream impedance scorecard (on a printout of them or on the screen), go back and look at the first principles chapter earlier in this book. See how consistent the VSIS is with them.

Assessing how cross-functional teams are consistent with the value stream impedance scorecard

The cross-functional team is the ideal case for building new products. Let’s see how having one reflects the VSIS.

Build small items of high value. This is independent of whether we have a cross-functional team or not. Notice how such a team would be able to create and build value, however.

Manage queues to reduce delays and handbacks in the workflow. With everyone focused on building the same product, a cross-functional team could work together to have few delays.

Get quick feedback. Cross-functional teams not only will be able to build items quickly and therefore get quick feedback, but they will also be able to get quick feedback between each of the steps.

Focus on high product quality – both from the stakeholders’ perception and from how the product was built. Achieving high quality requires everyone to agree on what that is. A cross-functional team is likely to be more aligned here than groups from multiple teams working together.

Keep workloads within the capacity of the people doing the work. It’s easier to gauge the work the team is able to do when they pull it together.

Keep all work and workflow visible. Keeping work visible across a team is much easier than across multiple teams. However, just having a cross-functional team doesn’t guarantee this.

Organize people and have them make agreements on how they work in order to reduce waiting for others. Cross-functional teams can avoid delays by coordinating the work to be done with each other.

Have development teams work primarily on one value stream. Organize people who have to support multiple teams to work on as few value streams as possible while still remaining appropriately loaded. Cross-functional teams are intended to be used for one product – one value stream.

Have people attend to the value stream. With cross-functional teams, much of the value stream is in the team.

Using the Value Stream Impedance Score Card: A Case Study

Many organizations have the challenge of not having a well-defined intake process prior to adopting agile. A lot of work is happening, but people aren’t sure what the work is, who is doing it, or at what stage the work is in. The table below illustrates how doing this adversely affects most of the vectors of the VSIS. And severely as well. In this mini-assessment, we turn the VSIS actions statements into questions by adding “did we” in front of each one.

Is VSIS being followed? YN
Did we build small items of high value?unlikely
Did we manage queues to reduce delays and handbacks in the workflow?X
Did we get quick feedback?X
Did we focus on high product quality – both from the stakeholders’ perception and from how the product was built?X
Did we keep all work and workflow visible?X
Did we organize people and have them make agreements on how they work in order to reduce waiting for others?X
Are people organized in a way that reduces waiting for others and handoffs?Unlikely
Did we have development teams work primarily on one value stream? Did we organize people who have to support multiple teams to work in as few value streams as possible while still remaining appropriately loaded?N
Did we have people attend to the value stream?N

Side Notes: VSIS Is about the impedance, not how to change it

The value stream impedance scorecard is focused on what helps or hurts the flow of value. It intentionally leaves out factors like how we got here, or how we can change it, or what factors help change it. These are critically important. They have been left out because we want the VSIS to be a measure of the resistance and an indicator of what we can do to improve things. We will deal with these other issues of how to change things to later chapters in this workbook.

Key Points

  • We can use each of the vectors to see how well we are doing
  • The value stream impedance scorecard provides a way of determining if a change in actions will improve the effectiveness of our value stream

How We’ve Manifested the Purpose

We started this chapter by stating, “we need a guide to help us see which of two or more options is better.” The Value Stream Impedance Scorecard provides us with questions to see how well we are doing. Each of these questions points out whether we are following the first principles of knowledge work.

Amplio Is a Pattern Language

The Challenge with Popular Frameworks

The advantage of frameworks is that they can focus adopters’ attention on what’s useful and can create alignment. They also provide ways to start quickly, and with relatively little training.

Popular frameworks, such as Scrum and SAFe, are based on values, principles, and practices. The frameworks are mostly defined by the practices. While practices can be added, substituting for presented practices typically means you won’t be adopting the framework anymore.

This puts the cart in front of the horse. Except for a few trivial, but useful, practices, no practices work everywhere. The situation within which they are being applied is important. This context must also include the skill set, knowledge, and motivations of the people who are adopting them. Not doing so means people may not have the skills, knowledge, or motivation to adopt the practices, and therefore, the framework properly.

Popular frameworks thereby present us with a two-edged sword. Ease for starting, but perhaps not fit for purpose. And there is another factor when we remember Edgar Schein’s maxim – “We don’t think and talk about what we see, we see what we are able to think and talk about.” This means that people will see what frameworks focus on. But these may not be appropriate for us.

A pattern language can avoid this dilemma by providing us with focus on what’s needed, options to make things fit for purpose, and a way to get a quick start that can also be used for ongoing learning.

What is a “pattern language”?

Patterns are “solutions to a recurring problem in a context.” The concept of patterns to be used in this manner was presented in Christopher Alexander’s “A Timeless Way of Being.”

Each pattern has:

  • A name so that we can identify them
  • A situation (context) in which they apply
  • An objective includes a why so we can understand its purpose
  • A set of implementations that can be used to implement it

A common pattern in the Agile space would be “planning event.” It applies when a team or teams needs to plan what’s going to be worked on over some future amount of time. Its objective is to create a plan to work from so that the team(s) can coordinate their work. There are many different implementations available. The practices presented in Scrum and SAFe can be thought of as a pattern. Just thinking about them can make both frameworks better if you substitute the practice used with a different pattern than meets the same objective.

A “pattern language” is a collection of patterns, designed to work together, that, when achieved, results in an effective way of creating value. All of these patterns are based on first principles so that people can both understand why they are needed and create alignment on achieving them. Each objective is provided with multiple ways of implementing it.

Frameworks need to provide structure and solutions while maintaining flexibility. It’s possible to make a framework more flexible by substituting patterns for the fixed patterns of frameworks. A pattern language provides a way of presenting what needs to be considered without the rigidness of the framework. This allows the framework to evolve as new concepts become available.

Patterns can provide this needed flexibility because it presents a set of solutions that adopters can pick from. This implies that the framework must include a method for selecting the appropriate pattern. Amplio Development provides this in its value stream impedance scorecard which is presented later in this book.

The Advantages of a Pattern Language

There are two common ways of attempting to adopt Agile.

The most common one is to adopt a framework or well-defined approach. Frameworks are popular because they clarify how people are to work together. It is easy to design a framework to specify this. Unfortunately, there is no universal framework that can work for everyone.

Scrum is the most popular team framework. But most teams have challenges with it because Scrum was designed for early adopters in a cross-functional team, building a new product, and being allowed to self-manage themselves. This, unfortunately, doesn’t describe that many teams using it.

Many teams have decided to create their own process, but this is often expensive and ripe with risk unless they have some deeply experienced people involved.

Amplio Development being a pattern language has the advantage of providing a well-defined approach that is fit for purpose. It provides a set that can be used to start with, that is tailored to the team(s) using it. Teams can adjust them as they learn.

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

Go to Being a Professional Coach


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