Vision without execution is hallucination.

—Thomas Edison

Iteration Execution

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 from every team, scaling is nearly impossible, and solution quality is compromised.

During the iteration, each team collaborates to define, build, and test the Stories they committed to 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 (DSU) events. 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 any challenges they are facing and makes small improvements every iteration. 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 developing high-quality system increments every 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 their 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 apply 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 events
• 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.

With this simple storyboard, the team just moves the red ribbon to the current day, providing an immediate and easy-to-understand visual assessment of iteration progress. It’s now clear that the iteration shown in Figure 1, which has only 5 days remaining, is at risk and the team should 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 physical 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 Agile Workspaces and Working Successfully in Agile with Remote Team Members articles contains further information on this topic).

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 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 so that team members can highlight the stories they are referencing. 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 will need to be resolved afterward.

High performing teams use the DSU to find opportunities to help each other so that the entire team succeeds in delivering its committed iteration goals. 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 discuss these topics in more detail. Ineffective DSUs may be a symptom of deeper problems that require a systemic approach for resolution, which often become the responsibility of the Scrum Master.

(Note: Although the DSU is a Scrum event, many Kanban Teams also hold a DSU in front of their Kanban board to coordinate work and identify bottlenecks or WIP problems.)

Improving Flow

Managing WIP

WIP limits provide a strategy for preventing bottlenecks 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 and its impact on flow.

Kanban teams explicitly apply WIP limits on their Kanban boards. ScrumXP teams may also use WIP limits. These can be explicit or implicit. An example of implicit WIP limits are when the team plans its work and takes on only the amount of stories that their capacity for the iteration predicts they can achieve. This forces the demand (negotiated iteration goals and stories) to match capacity. The iteration timebox also limits WIP by preventing uncontrolled expansion of work.

ScrumXP teams may also use explicit WIP limits on their storyboards. For example, in Figure 1 above, what would a developer do if there were no WIP limits and he or she finished story five ? The developer would probably start another story. But if a WIP limit of three is imposed on both the ‘development’ and ‘test’ stages, the developer would need to assist other team members before beginning a new story, 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 Solutions that promote a predictable development velocity. SAFe’s approach to Built-In Quality prescribes five practices that help ensure solutions quality at all levels:

• Achieve flow and continuous delivery by applying a test-first approach to specifying and building the system
• Apply agile architecture and design quality practices that create flexible systems that are easier to test and support future business needs
• Implement code quality by applying Test-Driven-Development (TDD), pair work, collective ownership, and coding standards
• Ensure system quality by continuously integrating the end-to-end system
• Achieve release quality through modular architectures that support smaller, more frequent component releases and an immutable infrastructure approach to changes that create more consistent, predictable releases

Ensuring that quality is built in from the beginning and at all levels makes delivering value quicker, easier, and less costly.

Continuously Accepting Stories

Stories are reviewed and accepted continuously throughout the iteration. The Product Owner compares the demonstrated functionality to the acceptance criteria specified in the story details. In addition there may be criteria documented in a Definition of Done (DoD) that every story needs to satisfy, such as Nonfunctional Requirements. The team reworks stories that are not accepted.

This approach ensures that 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.

Test Automation

By applying Behavior-Driven Development (BDD), the criteria for acceptable system behavior, as specified by the Product Owner and the other Agile team members, are converted to automated story-acceptance tests. As the system evolves, continuously running these tests helps assure that the previously developed and tested functionality still performs as expected even after it has been changed or interfaced with other components.

Automation also provides the ability to quickly regression test the system, enhancing continuous integration, refactoring, and maintenance.  Using BDD to document acceptance criteria as human readable, executable specifications encourages collaboration and helps teams keep the business goals in mind, at all times.

Continuous Integration and Deployment

Continuous integration as well as migrating work to a staging environment and even deploying to production, allows for a faster flow of value and validation of Feature 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.

Building Stories Incrementally

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 Agile teams to operate with a smaller increment of the working system, supporting continuous integration and testing. It allows 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 and risk, 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 of the ART’s program PI objectives. The teams plan, demo, and learn together, as illustrated in Figure 4, which avoids them focusing solely on local concerns. This alignment enables teams to more independently explore, integrate, deploy, and release value.

The Agile teams articles further describe their role in program execution.

Learn More

Last update: 10 February 2021