Amplio Body of Knowledge

Since Amplio is based on principles, it can incorporate any practice that makes sense for your context. In that sense, Amplio’s body of knowledge includes what’s available in Flow, Lean, The Theory of Constraints, Scrum, Kanban, SAFe and more. It only filters out practices that are misguided or have been diluted from their original intention. However, there are a few practices that were created by Al Shalloway (primary creator of Amplio) or others working with him. This page presents the most significant ones of these.

It also presents a few practices that Amplio’s principles and practices extend.

Essential Practices Not Found In Agile’s Popular Frameworks

The Generic Value Stream provides a way to do a Pareto analysis of an organization’s challenges in the context of their value streams.

Minimum Value Increments (MVIs) provide a counterpart to MVPs when one is extending an existing product. MVIs include the notion of “full-kitting” so that all parts of an organization are involved in providing value to its customers.

 Bridging Business With IT by Using the Customer Journey to Create MVIs. Innovation requires attending to how customers work.

Value Creation Structures vary for many reasons. Cross-functional teams and Agile Release Trains are just two of many.

Amplio Team Estimation is a more flexible, faster, and better estimation technique than the ubiquitous “Planning Poker.”

See below for more information.

 

The Generic Value Stream

Value stream mapping is an effective way to:

  • Identify where an organization’s challenges are.
  • Create alignment on how to work together.
  • Assist in creating an improvement path moving forward.

The challenge, however, is that value stream mapping takes a considerable amount of time. 

The “generic value stream”, created by Al Shalloway, enables a Pareto-style analysis that takes hours instead of days. It is done as a group exercise which also creates a deeper sense of community.

Minimum Value Increments (MVIs)

An MVI is a clear description of the minimum amount of value that can be realized. This means consumption by the intended customer, not merely deploying it.

It is not enough to build functionality to deliver. We must include all of the functionality and support information required for deployment. This would include marketing, sales, support, ops, etc. 

MVIs, therefore, incorporate full-kitting, which is the process of creating a checklist that contains all the elements that are necessary to complete a task or a project.”  Goldratt’s Rules of Flow, Goldratt-Ashlag, Efrat. 

Go here to see a detailed description of MVIs and how they relate to MVPs.

Bridging Business With IT by Using the Customer Journey to Create MVIs

Teams often get disconnected from the overall strategy of an organization. They also tend to focus on building the product and forget that other parts of the organization, such as marketing, support, legal, and others, need to be involved. While teams need to work in a way that works for them, they need to work within the context of the big picture. This requires having a method to remind them of the needs of the rest of the organization in getting a product out the door to the customer, including a long-term view of support.

By attending to the customer journey, teams can innovate more effectively. Amplio’s template that drives this also includes the needs of the rest of the organization so the big picture is not lost.

A related post is How to turn Scrum feature factories into innovation factories.

Value Creation Structures

Value creation structures describe how your people are organized and allocated to teams, trains, programs, or whatever you call groups of people. It is one of the most important aspects of your ecosystem. They are sometimes called Team Topologies after the book, one of several good references on them.

There are several ways to organize people. Here are a few of the most common.

  • Cross-functional teams.
  • Feature teams. Cross-functional teams that can build and deliver features but not cross-functional enough to create MVIs.
  • Component teams. Teams that can create, modify, and maintain components that are used by other teams to create and deliver releases.
  • Core teams. Collections of people that can mostly build a feature or MVI but sometimes require others to help them. This need may be satisfied with a combination of the “borrow member” or “clean up with kanban” pattern.
  • Borrow member. When one team lends a member of their team to another.  This is often useful when one team makes enough requests to another team where it warrants the team fulfilling the requests and lending a team member to the requesting team. When this happens, this person remains on their original team but works with the requesting team while they are useful.  They must attend required meetings from both teams (such as daily coordination meetings).
  • Shared team member. How team members needed across several other teams can be shared.
  • Clean up with kanban. When one or more individuals are required for more than one team. In this case their workload should be managed with each having their own kanban board.
  • Focused solution team. A team-of-teams consisting of feature teams, core teams and a limited number of individuals that have to work across the core teams. They are able to build and deliver either MVPs or MVIs. They are focused on the MVPs and MVIs they have in their backlog but can be available on a limited basis to other teams. They are the key to achieving agile budgeting by having FSTs aligned with the initiatives of the stakeholders. While reasonably stable, they will adjust according to need.
  • Dynamic feature team. Dynamic feature teams are useful when several small teams exist that are mostly independent from each other but every now and then must collaborate with each other.

Amplio Team Estimation

People are biased to underestimate the time it takes to get something accomplished. The planning fallacy is a term used by psychologists to describe our tendency to underestimate the amount of time it will take to complete a task. The term was first coined in 1977 by psychologists Daniel Kahneman and Amos Tversky.

To combat this, it is important to estimate against something. This is called relative estimation. When you estimate against a scale, you are almost certainly going to underestimate more than if you compare it against something you did before. This is one reason Planning Poker is ineffective – it measures against a scale, not past items that have been worked on.

Amplio Team Estimation is a true relative estimation technique created by Steve Bockman and refined by Al Shalloway.

Learn more here.

    Practices Amplio Enhances

    MVIs and the principles of removing delays in workflows can be used to enhance several popular Agile practices. These include:

    SAFe Practices

    Program Increment Planning can be greatly enhanced by using Minimum Business Increments. These prepare teams to know what can be released quicker going into the event. This avoids a lot of the freneticness seen in normal PI events. It also eliminates the waste that’s created by working on big things.

    Decouple value streams using Amplio’s value creation structures and factors for effective value streams.

    See more ways Amplio can assist adopters of SAFe here.

    Scrum Practices

    Focusing on using flow throughout the sprint can improve the sprint. While theoretically, this can be done in Scrum, it usually isn’t because it requires an understanding of the theories of flow, which Scrum doesn’t subscribe to.

    Daily scrums and retrospectives are improved by using theories of flow and focusing on quick feedback.

    Choosing the right practices for the context you are in is possible because of Amplio’s Factors for Effective Value Streams.

    Amplio Patterns

    ADD THIS.