Lean Agile Delivery is the application of an Agile Mindset to set and accomplish organizational goals. It is a collaborative approach where leaders and team members strive to apply the Agile Enterprise principles in their day-to-day work to deliver value to customers.

Lean Agile Delivery builds upon the following methodologies, practices and frameworks to help a single team or large enterprise accomplish whatever it is they’re trying to accomplish:

• Agile Manifesto and its Principles
• Agile Mindset and Agile Enterprise Principles
• Lean
• Organizational Action Research
• Design Thinking
• Team Effectiveness
• Project and Program Management Techniques
• Agile and Scaled-Agile Frameworks

Why do it?

In my experience, Agile teams (large or small) are incredibly predictable. Moreover, they’re able to predictably deliver quality solutions to problems in a highly sustainable way. It doesn’t start of that way, and it takes time to get there, but once they do, team members and customers alike see the value in what they do each in and every day.

With predictability, comes agility. Being able to predict likely outcomes allows teams to consider different scenarios as data evolves and potentially changes their current understanding. Predictability also helps teams establish sustainable workloads and allows them to allocate time for continuous improvement activities.

Agile teams are also customer obsessed. They quantify everything they do in terms of value for the customer and constantly look for a win-win-win scenario: Win for the customer; win for the company; and, win for each team member.

Lena Boiser wrote a solid article about Lean Agile Project Management and this concept directly applies to Lean Agile Delivery. The benefits she highlighted, and I agree with, are:

• Increase in customer value creation
• Reduced risk
• Improved process transparency and visibility
• Focus on data to drive change/decisions
• Better responsiveness to changing requirements
• Stronger team collaboration

The six Agile Enterprise principles are adapted from the twelve Agile Manifesto principles and simplified for use. In Stephen Covey’s book, The 7 Habits of Highly Effective People, he noted that principles mostly relate to human behaviour and govern interactions between people. These principles are intended to do just that and inform the work needed to help your organization or team adopt an Agile Mindset.

1. Prioritize delivery of customer value
   • Measure success by setting and achieving goals focused on delivering customer value – something your customers can demonstrate realizing with what you deliver
   • Verify and validate what constitutes value with real customers
   • Prioritize this principle over anything that could impede your ability to do so
2. Seek progress over perfection
   • Deliver as early and as often as possible
   • Perfection comes from putting it out there with real customers, learning from their feedback, and pivoting if required – or stopping if it’s good enough
3. Create alignment and accountability
   • Make goals, risks and how work gets done highly visible, including who is responsible and how they’re progressing on them
   • Break work down into smaller increments that enable individuals and teams to demonstrate progress towards realizing larger goals or reducing risk
4. Simplify the work
   • Once visualized, identify areas for improvement for how work gets done
   • Leverage hypothesis-based experiments on identified areas to make improvements
5. Trust people and teams to do their job
   • Distribute decision making to people closest to the problem
   • Trust people and teams to do the work right and encourage them to adjust if data identifies opportunity
6. Treat everything as a learning opportunity
   • Regularly reflect as a team on how work gets done, decisions get made, and how people interact
   • Promote learning, not in the traditional sense, but in everything people do

Organizations and teams that demonstrate living these principles have adopted the Agile Mindset.

Your Content Goes Here

Kanban is an ideal Agile framework for any scenario, really, since it can be used primarily as a lean approach to adopting and living both the Agile Enterprise Principles and the Agile Principles.

Kanban Principles

Kanban is a pull system – work is pulled into the system when the team has capacity, instead of having work assigned. Teams pull in work from a prioritized backlog. The work to build and prioritize the backlog is part of readying items to be worked on. This continuous prioritization enables teams to be always ready to adapt to changing priorities. It’s principles are:

1. Visualize Work
   • Make the current workflow transparent to everyone
2. Focus on Flow
   • Track time, improve workflow and resolve bottlenecks
3. Limit Work in Progress
   • Discourages multi-tasking by limiting the number of cards a team can in progress at any given time
4. Make Process Policies Explicit
   • Define and share them; what has to be true to move right
   • This also is another representation of the work to get to DoR and DoD
5. Enable Continuous Improvement
   • Implement experiments to learn & advance your process flow

Kanban is used in 3 key scenarios:

• Squad/Team level flow for completing work that is delivery focussed (i.e. stories) or more operational in nature (i.e. bugs, sustainment, etc.). All items moving through this flow gets to a place that meets Definition of Done (DoD),
• Planning flow for visualizing and managing the work required (i.e. Story Mapping, Design, Refinement, etc.) to get stories to a place that meets Definition of Ready (DoR), and
• Management flow for visualizing and managing the work not specifically related to story definition and completion (i.e. Risks, Release Management, Stakeholders, Dependencies, etc.).

The hierarchy of Kanban for Lean Agile Delivery is:

• Management: Milestones, Roadmap, Risks, Dependencies, etc.
• Planning/Delivery Readiness (i.e. work to meet DoR): Story Mapping, Design, Architecture, UX, Refinement, etc.
• Delivery (i.e. work to meet DoD): Stories, Bugs, Spikes

Management Kanban

A Management Kanban is used for visualizing and managing the work not specifically related to story definition and completion (i.e. Risks, Release Management, Stakeholders, Dependencies, etc.). The following Kanban example would be used by either Project or Program Leads (and even functional leaders) to visualize and manage the work required by them to reduce risk, ensure major milestones are successfully met and support the overall execution of the project, program or initiative.

Management Kanban Recommendations:

• Adopt a pull-based system that makes commitments on a regular basis (weekly/bi-weekly) by pulling items into To Do
• Implement WIP limits on To Do and In Progress that match the available capacity of the team
• Only pull into To Do the number of items that the team is likely to complete within the cadence they’re working within (i.e. the system from To Do onwards should flush within that time frame)
• Create a Milestone or Risk Swimlane for every major milestone or risk that will require work over multiple iterations/sprints to accomplish the desired outcome
• Break work items into smaller work items if they are too big to complete within a single iteration

Planning Kanban

A Planning Kanban is used for visualizing and managing the work required to get stories to a place that meets DoR (i.e. Story Mapping, Design, Refinement, etc.). The following Kanban example would be used by an integrated planning team to visualize and manage the readiness of a Program Increment (PI) if using SAFe or for maintaining an actionable backlog for one or more delivery teams. The only items visualized on this board would be stories.

Planning Kanban Recommendations:

• Adopt a pull-based system based on a set of policies that make up your DoR for stories
• Create a prioritized list of swimlanes by Epic or Feature being scoped for that PI or near-term set of priorities and group stories into their respective lanes
• Implement WIP limits on In Design and In Refinement that match the available capacity of the integrated planning team members
• Identify opportunities during Design and Refinement to split stories into smaller vertical slices as needed
• Separate boards can be setup to further break down the work during In Design or, if the workflow is simple, sub-tasks can be created within stories to manage the design work

Delivery Kanban

A Delivery Kanban is used for visualizing and managing work at the squad level that can be both stories and more operational items (i.e. bugs and spikes) and that gets those items to a place that meets DoD.  The following Kanban example would be used by teams and could contain stories, bugs and spikes. Only items that meet DoR make it to a team’s backlog and are subsequently prioritized by the Product Owner in collaboration with integrated team during Refinement.

Delivery Kanban Recommendations:

• Adopt a pull-based system based on a set of policies that make up your DoD for stories
• Create a prioritized list of swimlanes by story only if that helps with managing the work
• Implement WIP limits on every “In Progress” column (i.e. Development, Code Review, QA, PO Review)
• Visually block items that cannot move forward and swarm as a team to unblock them so that WIP limits are maintained
• Only use To Do if following Scrum and are making sprint commitments during Sprint Planning
• Make sure that it is technically possible to develop vertically sliced stories before having to move them alongthe workflow

When are delivery teams ready to adopt Kanban?

Kanban is an ideal Agile framework for any scenario, but it can be tricky to implement for teams if they don’t really understand it or are not technically setup for success. Typically, only teams that are more established and are ready to move into a pull-based system should adopt Kanban for Delivery.

Teams are ready when:

• They consistently split stories during refinement into work that could meet DoD within 1-3 days
  • Enables them to use story count instead of story size
• They vertically slice all stories that need to be split
• They are familiar with Feature-Driven Development (FDD) syntax and have applied it to addressing non-functional or purely technical requirements
• They have been actively executing Scrum and demonstrating the ability to ingest bugs into sprint without impacting scrum-based estimates
• They technically are able to complete ALL the work of a story through its specific delivery step without having to move to a subsequent step (i.e. A story can be fully developed before moving to Ready for Code Review, etc.)

Key metrics for Kanban

Agile Delivery makes data driven decisions based on a fully transparent look into how work is actually progressing. We measure the time it takes to complete work and apply those metrics into Monte Carlo simulations to predict likely future outcomes.

There are three key metrics for Kanban:

• Cycle time
  The total amount of elapsed time between when an item starts and when an item finishes. Alternatively, the total amount of elapsed time that an item spends as Work in Progress (WIP).
• Throughput
  The amount of work delivered over a specified period. We use average throughput to make predictions on when value will be delivered.
• Work in Progress
  The number of product backlog items that a team is currently working on. Limiting work in progress is one of the core properties of Kanban. It allows you to manage your process in a way that creates a smooth workflow and prevents overloads. It is also a very lean concept and core to optimizing a pull based system.

Meetings and cadence are structural elements that enable teams to sustainably deliver predictable results.

Meetings

• Every meeting has a purpose
• The recommended set of meetings (when realizing their purpose) should result in fewer “other” meetings and more focus time for individuals and teams

Cadence

• Cadence informs the schedule teams will be demonstrating the delivery of customer value
• Cadence also informs the schedule of events (meetings) that need to happen to support or guide the delivery of value
  • For instance, a 2 week delivery cadence will benefit from a different schedule of meetings than a 4 week delivery cadence
  • Typically, the longer the cycle time for delivering value, the less frequent the meetings required, but the higher the risk to delivery and a reduced ability to adapt to change if needed.
  • Teams need to find their balance and check in on it regularly

Whether you are following Scrum or Kanban or a combination of both, teams still need to establish a core set of meetings on a set schedule/cadence.

Program Ceremonies Meeting Schedule

Program Leadership Meeting Schedule

The ideal flow and purpose of meetings

Meetings and cadence only really start to matter once a program or team has enough work ready to begin delivering (i.e. enough stories that meet DoR). You can substitute program with project throughout this section.

• Whether teams are using Scrum or Kanban or a combination of both, they need an actionable backlog to work from, and
• Until teams have an actionable backlog, programs should focus on Planning activities to build one
  • Recommend working with a weekly cadence until enough stories meet DoR and teams can begin Delivery

Once teams get delivering, meetings and cadence focus on managing the delivery of work, preparing to deliver work, planning for the future and managing risks and dependencies.

1. The first program level meeting to kick off Delivery should be Sprint Alignment, held the afternoon before start of Sprint
   • Typically used when multiple teams are in place, this meeting ensures Program Leads and teams are aligned on what the immediate, short term and near term priorities are
2. If only one team exists, then begin with Sprint Planning if using Scrum or a Daily Stand Up if using Kanban
   • Both meetings focus on getting all team members aligned on what their priorities are and what they will be working on over the next day
   • Sprint Planning takes it several steps further and requires that team members align on a sprint goal and make a commitment to complete a predetermined set of stories to meet that goal (typically over a 2 week period)
3. If working with multiple teams, the next program level meeting should be Scrum of Scrums
   • The sole focus of this meeting is to highlight risks that teams have identified that could prevent them from realizing their sprint goal – in particular, risks or dependencies that cannot be solely managed within the context of the team (i.e. may need another team’s help or Program Leads’ assistance to remove blockers)
   • It’s also an important view for Program Leads into the likelihood of the program remaining on track to hit short term milestones
4. The Daily Stand Up becomes the primary meeting for team members to provide transparency into how things are progressing, hold each other accountable to their commitments and be there for each other if they need help
5. As the sprint executes, teams need to participate in Product Backlog Refinement
   • The purpose of this meeting is to help ready stories for future sprints all while engaging team members with defining their future work
   • Only stories that are Ready for Refinement should be brought into this meeting
6. Typically, team members and program leaders need time to work through things with their respective team members as delivery happens
   • Collaboration Time is a regularly scheduled meeting that creates space for teams to collaborate on topics they need to work through and, when done regularly enough, can completely remove the need for ad hoc meetings within the context of the program
   • Collaboration Time can be used by teams for additional time for Product Backlog Refinement, working through actions items triggered by a Sprint Retrospective, Knowledge Transfer sessions with Solution Design or UX, etc.
7. On a weekly basis, program leaders should hold a Program Risk Meeting
   • The purpose of this meeting is to engage in open and transparent dialogue about the risks that could prevent the program from realizing its milestones plus agree on their likelihood and impact, resolution strategy and accountability to manage the risk
   • This isn’t always a pretty meeting, but it’s a critical meeting to practice and demonstrate living the Agile Enterprise Principles
8. Once teams complete a sprint, in the spirit of Continuous Improvement, they should conduct a Sprint Retrospective and reflect on how the last sprint went plus agree on one or more actions to make improvements in future sprints
   • This is the meeting that focuses on the “how” teams work together and it’s a critical input, supported by data, into developing them into high performance teams
9. The final meeting of any sprint is the Sprint Review
   • This meeting’s purpose is to inspect and adapt. That means, demonstrate what each team has accomplished in the sprint with real customers, collect their feedback and determine if we need to adapt based on it
   • In traditionally fixed-ish scope projects, the adapt part of this meeting tends to break down in favour of hitting higher level milestones, but it’s something programs could strive for once they get into operational mode

The other regularly scheduled meetings are set up based on the lifecycle of the Initiative and the teams using them. They are:

• Bug Triage and Bug Retrospective
• Program Demo
• Program Leads Retrospective
• People Leadership
• Steering Committee