One of the 7 Principles of Lean Development, “Amplify Learning”, specifically targets the agile practice around “Inspect and Adapt”. In fact, the Lean Principle “Amplify Learning” is the predecessor to the agile practice. At the project level, you can think about amplifying learning in a variety of ways. Daily, we check in with one another about, “What’s happening that could be blocking us from success, and how can we adapt in order to remove that block?” And, at the end of each Iteration, a team pauses in order to demonstrate releasable tested functions (RTFs) and determine how to proceed in the next Iteration. They base their plan on a review of their successes and challenges in the last Iteration. So, what happens at the Program level when agile is being applied across multiple project teams within a Program? How do we still inspect and adapt effectively? This is where revisiting the Lean Principle “Amplify Learning” comes in mighty handy.
“Amplify Learning” means planning to experiment, checking the data around the results, and then incorporating what is learned. For Programs, this means deriving metrics that can be cross-team applicable, not just intra-team optimized. How do we accomplish this? That may require “leaning” on another of the 7 Principles: “See the Whole”.
Here are seven practices that “Amplify Learning” for Programs:
- Use coordinated Iterations across teams to increase inspection and adaption
Project teams within a Program manage their integration risk and sub-optimization issues by setting a common rhythm across all teams: one common Release Plan with the same number of Iterations, all of the same fixed duration, for all teams. All teams commit to the common plan in a Program-wide Release Planning meeting. Thus, at the end of each Iteration timebox, the Program Manager, Product Owner, representatives from each team, and stakeholders inspect the overall flow of the Program: Where are the bottlenecks? What resource constraints continue to grab us? What Program risks persist? Where are we slipping in quality or in function delivery at the Program level?
- Increase osmotic communication
Group programming and pair programming within each project team creates flow for each team. Optimizing flow for the entire Program relies on this team-level engineering discipline. When team members amplify their learning in this way, they promote rapid osmotic emergence and convergence of the useful Program-level standards and best practices. Norms across the teams buoy the stability of the overall Program.
- Create total transparency across teams everyday
Backlogs, burndown charts, and resource loading must be tooled and completely visible across the entire Program, regardless of the number of teams or locations of teams. A common automated Product Backlog coupled with an automated Iteration Backlog for each project team is a must. Programs require nothing less if they are to be able to amplify learning daily, from iteration to iteration, and from release to release.
- Apply tools to maintain information and create visibility
Programs must collect data (metrics) and incorporate learning across all teams in order to take advantage of the common rhythm of the team iterations. That means implementing tools that can manage the data, distribute the data, and then track the trends of the data iteration over iteration across all teams. A team-level dashboard as well as a Program-level dashboard has to be visible to all stakeholders across all teams. QA and documentation must have high visibility across all teams in order to plan aggressively and integrate fully for product release.
- Hold daily Scrum of Scrums across teams
Once each project team has had its Daily Standup, it’s time to check-in across projects via a meeting of the ScrumMasters or Coaches. In the Scrum of Scrums, a representative from each team checks in with the pulse of the team and turns to the other participants for assistance in removing impediments. Each day, the participants check-in with one another on their action commitments from the previous day. They amplify learning across teams in the Program by rigorously checking in with one another and upholding their commitments.
- Hold a weekly MetaScrum across stakeholders
Issues that extend beyond the authority or “radar” of the Scrum of Scrums elevate to a weekly meeting of the Program stakeholders. So, not just inter-team issues, but high-level Program-level impacts are addressed. The stakeholders commit weekly to the gnarly issues that can extend beyond the teams, the IT organization or even across divisions. Each week, each stakeholder is held accountable for having resolved the issue for which they took ownership in the previous meeting. No excuses. In this way, stakeholders inspect and adapt in an urgent, virtuous cycle, setting and meeting audacious Program goals.
- Hold a Program-wide Release Retrospection at the end of each product release
Once the set of Iterations timeboxes have completed, the entire Program must pause to evaluate the load and flow of the previous Release: What did we plan during the Release Planning meeting? What did we manage to accomplish by the end of the Release? What new practices did we invite during the Release? What worked well during the Release? What challenges hampered us during the Release? What trends in metrics did we notice over the course of the Release? What issues and concerns still exist? Given the Program team responses to these questions, the entire group then determines: What new practices should we implement in the next Release? What new priorities should be addressed in the next Release? How should we re-shuffle resources across teams? What goals should we set for the Release? What “inspect and adapt” practices need to be amplified?
Amplifying learning means attacking any issue, any risk, any impediment, any waste with a vengeance at any time. A Program that implements the seven practices of “Amplify Learning” listed above will reap the benefits of more reliable product releases through better planning and better responses to the uncertainties that may arise. Pause, refresh, retrospect, go. Do this daily, every Iteration, every Release across all teams and all stakeholders.
RallyDev.com
