Vision without execution is hallucination.

—Thomas Edison

 

Iteration Execution

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, 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. 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.

These completed stories are demoed throughout the iteration and 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.

Details

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 developing 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 part of a larger purpose, which is 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.

The main 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 – this avoids mini-waterfalls within the iteration
  • Constant communication – continuous communication and synchronization via DSU meetings
  • Improving flow – optimizing flow by managing Work in Process (WIP), building quality in, and continuously accepting stories throughout the iteration
  • Program execution – working together as an ART to achieve program PI objectives

Tracking Iteration Progress

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 similar to Figure 1.

Figure 1. Tracking progress with a team storyboard

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. It’s now clear that the iteration shown in Figure 1 is at risk and the team can 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. But this is usually in addition to the BVIR.

Constant Communication

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.

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 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.

Improving Flow

Managing WIP

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 may also use WIP limits. These can be explicit or implicit. For example, implicit WIP limits are when the team plans its work and takes on only the amount of stories that their velocity predicts they can achieve. This forces the demand (negotiated iteration goals and stories) to match capacity (e.g., 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 shortest sustainable lead time. But 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 most significant 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. This way, problems can be addressed quickly and efficiently and avoids building new functionality on top of work that is not fit for purpose.  Further, the team avoids the context switching that otherwise occurs, when rework is required. The team reworks stories that are not acceptedFigure 1 illustrates an example of an iteration with too much WIP and insufficient flow.  After six days, the team has only moved one story to the ‘done’ state.

Test Automation

Where possible, the criteria for acceptable system behavior, as specified by the Product Owner and the Agile team members, are converted to automated story-acceptance tests.  As the system evolves, continuously running these test helps assure that the solution previously developed and tested still performs the same way after it was changed or interfaced with other components. Automation also provides the ability to quickly regression test the system, enhancing continuous integration, refactoring, and maintenance.  Documenting acceptance criteria as human readable, executable specifications encourage closer collaboration, helping teams keep the business goals in mind, at all times.

Continuous Integration and Deployment

Continuous integration at the team, system, and solution levels, as well as migrating work to a staging environment and even deploying to production allow a faster flow of value and validation of the benefit hypotheses.  The Continuous Integration and Continuous Deployment articles further describe these practices.

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.

 

Figure 2. Avoid the mini-waterfall with cross-functional Iterations

Building Stories Incrementally

Figure 3 illustrates how implementing stories in thin, vertical slices is the foundation for incremental development, integration, and testing.

Figure 3. Implementing Stories in vertical slices is the key to incremental development

Building stories this way 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. Incrementally implementing stories helps reduce uncertainty, validates architectural and design decisions, and promotes early learning and knowledge sharing.

Focusing on Program Execution

The ultimate goal of all Agile teams is the successful execution the ART’s PI objectives. Figure 4 shows that teams: plan, integrate and demo together; deploy and release together, and learn together; to avoid focusing solely on local concerns.

Figure 4. Agile teams collaborate to achieve the program PI objectives

The Agile Teams and Dev Team articles further describe their role in program execution.


Learn More

[1] Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011.

Last update: 6 November 2017