Amplio@Teams is a method for creating effective team-level workflows in knowledge work. It is based on Flow, Lean, the Theory of Constraints, and how people learn. We have found that the following attitudes and actions are helpful to be effective:

  1. Identify your stakeholders
  2. Clarify what success means to each of them.
  3. Taking a systems-thinking approach to look at the whole and understand the system creates much of the present behavior.
  4. Attend to the value stream and focus on quick releases of high-value items.
  5. Recognize that there are no universal practices but that universal principles can be used to decide which practices best fit our situation.
  6. Specify an essential set of objectives that enable teams to be effective. Include the rationale for each of these objectives.
  7. Provide options on how to implement each of these objectives
  8. Provide insights on the cause and effect of people’s actions to navigate the complexity of product development.
  9. Quickly identify a fit for purpose starting point
  10. Create workflows that remove both delays in work and achieve quick feedback. Doing this will eliminate a significant amount of waste.
  11. Avoid working on too many things by only pulling work when there is capacity and by finishing items when possible
  12. Continuously learn by seeing where delays and errors are injected into the work
  13. Teach people how to solve common challenges many Agile teams face to learn to solve their unique problems.

A Simple Agile Approach Based on Getting Feedback Quickly

This simple approach gives teams a way to start Lean-Agile in a non-disruptive manner that illustrates the fundamental principles of Lean-Agile. A case study is presented after it to facilitate understanding. 

Doing the above requires teaching people in a way that avoids overloading them. That allows for using just an essential set of concepts and expanding it over time.  Learn the essence of Agile at the team to start and then add more over time. A simple set of actions that can improve how we work. The key is to manage the amount of new information provided to the team over a short period to avoid overloading them.

The essence of Agile is delivering value quickly by focusing on working on small items while getting quick feedback and having teams manage their workload via pull methods. Accomplish this by attending to the entire value stream and eliminating the waste caused by misunderstood requirements, errors, and delays.

Consider how much of your organization’s work has been due to:

  1. Misunderstanding requirements from the customer or product owner
  2. Writing stories that implement the wrong functionality
  3. Programming errors that were not detected for a long time; this often results in it taking longer to fix than if it had been immediately detected.
  4. Having a misunderstanding between teammates that results in handbacks and extra work
  5. Multi-tasking

Now consider this. What if you focused on getting feedback at all levels of work? When you finish something, look to see what else you could complete that would provide feedback on what’s been done. You can manage your work as follows:

  1. Organize your people into a cross-functional team. The team should have sufficient domain knowledge and skills to create the product. This includes discovering what it needs to be.
  2. Create a product backlog that contains the requirements of what needs to be provided to the stakeholders.
  3. Work on small batches of work, preferably no more than one week’s worth. Only pull work from the backlog when you have the capacity to finish it. Too much work creates delays and waste.
  4. Find which functionality can be delivered first. The smaller, the better since that will shorten the time to create it and enables quicker feedback. If this is a new product and you aren’t sure what the smallest item of value is, decide on the smallest item of value that moves you toward being able to validate what you are doing. Build that, show it to the customer and get feedback.
  5. Build your work in a high-quality manner. If the product is software, then build it in small end-to-end slices. Don’t put in extra code to make it changeable, but consider how the code may need to change.
  6. Get an understanding of how the person specifying the requirements will validate them. At a minimum, when a requirement is given, ask, “how will I know I’ve done that?”
  7. Try to avoid handoffs. When necessary, the people involved should have a conversation about the work. View handbacks as having done an improper handoff and make corrections for the future.
  8. Focus on achieving quick feedback by keeping the amount of work in process within the team’s capacity. When someone finishes something, have them help finish something else before starting something new.
  9. Finish a feature before starting another feature. Finish function that’s part of a release before starting part of another thing that will be released.
  10. Have a daily meeting where people discuss their insights and challenges. This part of the meeting shouldn’t take more than 15 minutes. Schedule an additional 45 minutes to use to solve any challenges uncovered. Solving challenges as discovered is essential. Otherwise, you are hoarding them and causing waste to occur until you solve them.
  11. Have all work be visible and working methods be explicit
  12. Do what it takes to eliminate delays in your workflow, as these will slow down work, delay value delivery, and magnify the impact of errors.

You can start applying the above to any approach you are taking.  The key is to observe when delays occur. And notice how these delays cause extra work. Unplanned work. Wasted work. We want to avoid these delays. The first step is seeing them. When visible, many of these delays can be eliminated. Some common delays are the time from when:

  • you get a requirement until you use it
  • a misunderstanding happens, and it is discovered
  • a coding error is made until it is detected
  • an agreement is made between teams on how to integrate and when integration starts
  • work is started on building a release until it’s completed
  • work is started on a feature until it is completed
  • work is started on a story until it is completed.

Take a few minutes for each and reflect on why these delays create additional work or risk.

A Case Study

This case study is provided to give a specific example. It was based on visibility, explicit workflow, a focus on deliverable chunks of value, and immediate solving of challenges.


Cross-functional team of four creating training materials. One person on the team had a more profound experience than the others. He was considered the subject-matter expert but had no authority over what content to put in. That was a team decision. 

Agreements made among team members

  • No one had authority over decisions, but they would be made as a group.
  • Have daily discovery and fix sessions. Each was scheduled for an hour, but if there were no issues, we wouldn’t hold them. The meeting had two parts, the first a quick session describing the issues (5-10 minutes typically), with the second being a meeting to fix them. Only those needed would attend. This enabled identifying issues and immediately addressing them. This more extended segment would only take place when needed.
  • When a problem was found in how we were working, a quick meeting would take place if it could be solved immediately with just two people. Otherwise, it would get discussed in the following daily.
  • All work was to be visible using Kanban-style boards to see where everyone was.
  • We were to chunk up work on a weekly basis but would strive to finish it early to gain some slack for the next week if needed.
  • We would interact with customers as much as possible.  

Using Feedback to Manage Unexpected Events

Unexpected events are a way of life in product development. Learning what will make a difference to customers usually has to be discovered through creating a series of small features, showing them to customers, and getting feedback on their actual value. This underscores the importance of short feedback cycles. Having them enables the process mentioned above to go more quickly.

As we will see later in the book, much of the unpredictability in knowledge work comes more from people not following good practices. However, external events are unforeseen. To deal with them, we must be in a state that allows effective pivoting.

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