Vision without execution is hallucination.
Iteration Execution is how Agile teams manage their work throughout the iteration timebox, resulting in a high-quality, working, tested system increment.
Each Agile team has a single focus: to develop an increment of an effective, high-quality, working, tested system within a short timebox. This is the fundamental challenge of every team, Agile Release Train (ART), and Solution Train. No matter the preparation, no matter the planning, without effective iteration execution, scaling is nearly impossible and solution quality is compromised.
During the Iteration, the team collaborates intensely to define, build, and test the Stories developed in the course of Iteration Planning. They track the iteration’s progress and improve the flow of value by using story and Kanban boards and Daily Stand-up (DSU) meetings. They deliver stories throughout the iteration and avoid ‘waterfalling’ the timebox. They apply Built-in Quality practices to build the system right.
All of these are demonstrated at the Iteration Review. During the Iteration Retrospective, the Agile team reflects on their practices and challenges and makes small improvements every increment. They work effectively with other teams on the train and participate in the System Demo.
Empowering Agile Teams to focus on rapid value delivery fuels them with energy, motivation, and purpose. It instills a better sense of mission than traditional management and development models. The centerpiece of all this goodness is the effective execution of each iteration. Teams employ a variety of practices to achieve that result, but the focus is always the same: to deliver the stories they committed to during iteration planning in order to meet the Iteration Goals.
But even with effective, local iteration execution, teams are part of a larger purpose, which is optimizing program execution, one of the four Core Values of SAFe. To achieve this, teams operate in the context of the Agile release train, which guides teams toward agreed-to team and program Program Increment (PI) Objectives. All teams use the same iteration cadence and duration to synchronize their work for integration, evaluation, and demonstration during the iteration review and the system demo.
The key elements of a successful iteration execution include:
- Tracking iteration progress – Using story and Kanban boards to follow the progress of the iteration
- Building stories serially and incrementally – Avoiding mini-waterfall and building stories incrementally
- Constant communication – Continuous communication and synchronization via daily team stand-up meetings
- Improving flow – Optimizing flow by managing Work in Process (WIP), building quality in, and continuously accepting stories
- Program execution – Working together as an ART to achieve program PI objectives
Tracking Iteration Progress
Tracking iteration progress requires visibility into the status of the stories, defects, and other activities that the team is working on. For this purpose, most teams use a Big Visible Information Radiator (BVIR) on a wall in the team room. Kanban teams use their Kanban board, and Scrum Extreme Programming (XP) teams would use a storyboard, perhaps similar to Figure 1.
With this simple storyboard, the team just moves the red ribbon to the current day, providing an easy-to-understand visual assessment of where the team stands in the iteration. (Note how clear it is that the iteration in Figure 1 is at risk.) With that information, the team can discuss what is needed to successfully complete the iteration. If a remote participant or key stakeholder needs status information, the team can share it on a webcam, send it via email, or post it in a wiki. At scale, of course, virtually all Agile teams use contemporary Agile project management tools to capture stories and status, defects, test cases, estimates, actuals, assignments, burn-up, etc. But this is usually in addition to the BVIR.
An open environment and collocation are keys to team collaboration. Otherwise, pauses due to questions and assumptions will quickly cause delays in value delivery. In the worst case, if teams are distributed, they can establish an open communication environment by leaving webcams, instant messaging, and other collaboration tools in an always-on state.
The Daily Stand-Up
Each day, the team meets at the same time and place to coordinate their work by answering the following questions:
- What did I do yesterday to advance the iteration goals?
- What will I be able to complete today to advance the iteration goals?
- What’s preventing us from completing the iteration goals?
The DSU is key to team synchronization and self-organization. It’s most effective when held in front of a BVIR that highlights the stories that are the objective of the iteration. The DSU is strictly timeboxed to 15 minutes and is not a problem-solving meeting. Rather, its purpose is to identify issues, dependencies, and conversations, many of which need to be resolved afterward. The Scrum Master writes down topics that need further discussion on the ‘meet after’ board. During the meet after, only the involved parties stay to talk. Ineffective DSUs are symptoms of deeper problems that require a systematic approach for resolution, which often becomes the responsibility of the Scrum Master.
Note: Although the DSU is a Scrum construct, many Kanban Teams also hold a DSU in front of their Kanban board to coordinate and inspect it for bottlenecks or WIP problems.
WIP limits provide a strategy for preventing bottlenecks in development and helping improve flow. They also increase focus and information sharing, while fostering collective ownership. All SAFe teams should have a solid understanding of their WIP and flow.
Kanban teams explicitly apply WIP limits. ScrumXP teams also use WIP limits. They can be explicit or implicit. For example, implicit limits are when the team plans its own work and takes on only the amount of stories that their velocity predicts they can achieve. This forces the input rate (negotiated iteration goals and stories) to match capacity (ex., the team’s velocity). The iteration timebox also limits WIP by preventing uncontrolled expansion of work.
ScrumXP teams may also use explicit WIP limits on their storyboard. For example, in Figure 1 above, what would a developer do if there were no WIP limits and he or she finished story five above? The developer would probably start another story. But if a WIP limit of three is imposed on the in process and test stages, the developer would need to help test stories instead, and throughput would increase. To understand more about WIP limits, refer to SAFe Principle #6.
Building Quality In
ARTs execute and deliver new functionality with the fastest sustainable lead time. But in order to do that, they must create high-quality systems that promote a predictable development velocity. SAFe prescribes a set of five quality and engineering practices that contribute to the built-in quality of even the largest Solutions:
Ensuring that quality is built in from the beginning makes delivering value quicker, easier, and less costly.
Continuously Accepting Stories
Accepting stories continuously improves flow. (Refer to Figure 1 for symptoms of a nonflowing iteration. Notice that they are six days in, and only one story has been accepted.) Teams demo stories as soon as they are ready, not waiting for the iteration review. Stories that are not accepted are reworked by the team. This way, problems can be addressed quickly and efficiently. The teams don’t build new stories on top of nonworking stories, and they avoid the context switching that otherwise occurs.
Where possible, the criteria for acceptable system behavior, as specified by the Product Owner and the Agile team members, are converted to story-acceptance tests. As the system evolves, they can be run repeatedly to ensure fitness for use and continued system conformance. Automation also provides the ability to quickly regression test the system, enhancing continuous system-wide integration, refactoring, and maintenance. These tests are often created in a business-readable, domain-specific language, which creates a potentially automatically executable specification and test of the system.
Continuous Integration and Deployment
Teams must also continuously integrate their work at the team, system, and solution levels. They must strive to move work to a staging environment and even deploy to production as quickly as possible to validate hypotheses and improve the flow of value.
Building Stories Serially and Incrementally
Avoiding the Intra-iteration Waterfall
Teams should avoid the tendency to waterfall the iteration and instead ensure that they are completing multiple define-build-test cycles in the course of the iteration, as Figure 2 illustrates.
Building Stories Incrementally
Figure 3 illustrates how implementing stories in thin, vertical slices is the foundation for true incremental development, integration, and testing.
This enables a short feedback cycle and allows the Dev Teams to operate with a smaller increment of the working system, allowing continuous integration and testing. It allows Dev Team members to refine their understanding of the functionality, and it facilitates pairing and more frequent integration of working systems. The dependencies within and across teams and even trains can be managed more effectively, as the dependent teams can consume the new functionality sooner. This helps reduce uncertainty, validates architectural and design decisions, and promotes early learning and knowledge sharing.
Focusing on Program Execution
While successful iterations are important, the ultimate goal of all teams is the execution of successful program increments. To help ensure that teams don’t focus solely on local optimizations, SAFe teams plan together, integrate and demo together, deploy and release together, and learn together, as Figure 4 shows.
Learn More Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011.
Last update: 17 October, 2017