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—done 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 during Iteration Planning. They track the iteration’s progress, and improve the flow of value by using story and Kanban boards and daily stand-up 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 the team with energy, motivation, purpose, and a better sense of mission than that available with traditional management and development models. The centerpiece of all that goodness is the effective execution of each Iteration. Teams employ a variety of practices to achieve this result, but the focus is always the same: delivering 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 (ART), which coordinates teams toward agreed-to Team and Program PI Objectives. All teams use the same iteration cadence and duration to allow their work to be synchronized for integration, evaluation, and demonstration by the team 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 track the progress of the iteration
- Building stories serially and incrementally: avoiding mini-waterfall and building stories incrementally
- Constant communication: constant communication and synchronization via daily team stand-up meetings
- Improving flow: optimizing flow by managing 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 during the iteration. Most teams use a big visible information radiator (BVIR) on a wall in the team room for this purpose. Kanban teams use their Kanban board, and ScrumXP teams would use a story board, perhaps like the one in Figure 1.
With this simple story board, the team just moves the red ribbon to the current day. This provides an easy-to-understand visual assessment of where the team is in the iteration. (Note how it is clear 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 e-mail, 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, delays due to questions and assumptions will quickly cause delays in value delivery. Where, in the worst case, 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 (DSU): Each day, the team meets at the same time and place to coordinate their work by answering the following questions:
- What have I done yesterday to advance the iteration goals?
- What will I be able to complete today to advance the iteration goals?
- What is getting in our way of completing the iteration goals?
The DSU is key to team synchronization and self-organization. It is most effective when it is held in front of the 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. It is a primary mechanism for identifying issues, dependencies, and conversations, many of which need to happen afterward. The Scrum Master writes topics that need further discussion on the “Meet After” board. During the Meet After, only the involved parties stay to discuss. Ineffective DSUs are symptoms of deeper problems that require a systematic approach that often falls to the Scrum Master to facilitate.
Note: While the DSU is a Scrum construct, many Kanban Teams also hold a DSU in front of their Kanban board to coordinate and inspect the board 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, and they foster 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 when the team plans their 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 (the team’s velocity). The iteration timebox also limits WIP by preventing uncontrolled expansion of work.
ScumXP teams may also use explicit WIP limits on their story board. For example, in Figure 1 above, what would a developer do if there were no WIP limits and he or she finished story 5 above? They would probably start another story. If a WIP limit of 3 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
Agile Release Trains execute and deliver new functionality with the fastest sustainable lead time. In order to do so, they must create high-quality systems that promote a predictable development velocity. SAFe prescribes a set of five quality and engineering practices that materially contribute to the built-in quality of even the largest Solutions: Test-First, Continuous Integration, Refactoring, Pair Work, and Collective Ownership. 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 again to Figure 1 for symptoms of a non-flowing iteration; 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 occurs otherwise.
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 that can be run repeatedly to ensure fitness for use and continued system conformance as the system evolves. 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, thereby creating the “automatically executable specification and test” of the system.
Continuous Integration and Deployment
Teams must also continuously integrate their work both at the team, and the 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 for continuous integration and testing. It enables Dev Team members to refine their understanding of the functionality, and it facilitates pairing and integration of working systems more frequently. 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 updated 20 June, 2017