Vision without execution is hallucination.
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 discussed and selected 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.
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.
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.
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. 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 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 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 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 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’s Built-In Quality prescribes five practices that help ensure quality at all Solutions levels:
- Achieve flow and continuous delivery by applying a test-first approach to specifying and building the system
- Apply 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
- Create 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
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 accepted. Figure 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.
By applying Behavior-Driven Development (BDD), 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. 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 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.
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 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 of 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.
Learn More Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011.
Last update: 17 October 2018