Vision without execution is hallucination.
—Thomas Edison
Iteration Execution is how Agile Teams manage their work throughout the Iteration timebox, resulting in a high-quality, working, tested system increment.
Developing high-quality systems is a challenge for every Agile team, Agile Release Train (ART), and Solution Train. No matter the preparation and no matter the planning, without effective iteration execution, scaling is nearly impossible and solution quality is compromised.
During the iteration, each team collaborates to define, build, and test the Stories developed in the course of Iteration Planning. The team members 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.
These completed stories are demoed throughout the iteration and at the Iteration Review. During the Iteration Retrospective, the Agile Team reflects on its practices and challenges and makes small improvements at every increment. The team also works effectively with other teams on the train and participates 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 this approach is the development of high-quality system increments during the 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 to meet the Iteration Goals.
But even with good, local execution, teams are always part of a larger purpose—namely, optimizing program execution, one of the four Core Values of SAFe. Agile Teams operate in the context of the ART, which guides teams toward the agreed-to team and Program 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 system demo.
Successful iteration execution relies on the following activities:
Tracking iteration progress – The team uses either a storyboard or a Kanban board to follow the progress of the iteration.
Building stories serially and incrementally – This practice avoids mini-waterfalls within the iteration.
Constant communication – Continuous communication and synchronization via DSU meetings are key elements.
Improving flow – The team optimizes flow by managing Work in Process (WIP), building quality in, and continuously accepting stories throughout the iteration.
Program execution – Teams work together as an ART to achieve program PI objectives.
Tracking iteration progress requires visibility into the status of user stories, defects, and other team activities. 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, while ScrumXP teams would use a storyboard, perhaps one 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 iteration progress. In Figure 1, it’s clear that the iteration is at risk; the team can use the storyboard to figure out the best way of completing the iteration. The storyboard can be shared with remote participants or stakeholders using a webcam, email, wiki, or Agile project management tooling, although this means of communication usually complements the BVIR, rather than replacing it.
An open work environment and collocation of team members are essential to collaboration. Otherwise, delays in value delivery will rule the day. If a team is geographically distributed, they can improve communication by leaving webcams, instant messaging, and other collaboration tools in an always-on state.
Each day, the team members meet at the same time and place to coordinate their work by having each member answer 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 useful when held in front of a BVIR that highlights the stories that are part of the team’s PI objectives. The DSU is strictly timeboxed to 15 minutes and is not a problem-solving or status meeting for management. Instead, its purpose is to coordinate the team’s activities and raise blocking issues and dependencies, 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, and some ScrumXP teams also use WIP limits. These limits can be either explicit or implicit. For example, WIP limits are implicit when the team plans its work and takes on only the number of stories that their velocity predicts they can achieve. This forces the demand (i.e., the negotiated iteration goals and stories) to match the capacity (e.g., the team’s velocity). The iteration timebox also limits WIP by preventing uncontrolled expansion of work.
In an alternative approach, some ScrumXP teams may use explicit WIP limits on their storyboard. For example, in the situation depicted in Figure 1, what would a developer do if there were no WIP limits and he or she finished story 5? The developer would probably start another story. But if a WIP limit of 3 was 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.
ARTs execute and deliver new functionality with the shortest sustainable lead time. 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 contribute to the built-in quality of even the most significant Solutions:
Test-First
Continuous Integration
Refactoring
Pair work
Collective ownership
Ensuring that quality is built in from the beginning makes the delivery of value quicker, easier, and less costly.
Accepting stories on a continuous basis improves flow. With this approach, problems can be addressed quickly and efficiently and the team avoids building new functionality on top of work that is not fit for purpose. Further, the team avoids the context switching that might otherwise occur when rework is required. When it continuously accepts stories, the team reworks stories that are not accepted. Figure 1 illustrates an example of an iteration with too much WIP and insufficient flow: After six days, this team has moved only one story to the ‘done’ state.
Where possible, the criteria for acceptable system behavior, as specified by the Product Owner and the Agile Team members, should be converted to automated story-acceptance tests. As the system evolves, continuously running these tests helps assure that the solution previously developed and tested still performs the same way after it has been changed or interfaced with other components. Automation also provides the ability to quickly regression-test the system, which in turn enhances continuous integration, refactoring, and maintenance. Documenting acceptance criteria as human-readable, executable specifications encourages closer collaboration, helping teams keep the business goals in mind at all times.
Continuous integration at the team, system, and solution levels, as well as migrating work to a staging environment and even deploying to production, allow for a faster flow of value and validation of the expected benefits. The Continuous Integration and Continuous Deployment chapters describe these practices in more detail.
Teams should avoid the temptation to waterfall the iteration. Instead, they should ensure that they are completing multiple define–build–test cycles in the course of the iteration, as shown in Figure 2.
Figure 3 illustrates how implementing stories in thin, vertical slices is the foundation for incremental development, integration, and testing.
Building stories this way enables a short feedback cycle and allows the Dev Teams to work with a smaller increment of the working system, which in turn facilitates continuous integration and testing. This approach helps Dev Team members refine their understanding of the functionality, and it supports 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. Incrementally implementing stories helps reduce uncertainty, validates architectural and design decisions, and promotes early learning and knowledge sharing.
The ultimate goal of all Agile Teams is the successful execution of the ART’s PI objectives. Figure 4 shows that teams plan, integrate, and demo together; deploy and release together; and learn together. Collectively, these actions help teams avoid focusing solely on their own local concerns.
The Agile Teams and Dev Team chapters further describe these teams’ role in program execution.
LEARN MORE
[1] Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011.
