What does it mean for a team to develop software in an iterative fashion? In the wash of various processes within the agile ecosystem, iteration has come to be an overloaded term used with little thought to its purpose or the context for those systems.
The focus for this article is not iteration upon the products in the team’s portfolio, but rather the team iteratively delivering the work in their backlog.
In my experience, a healthy iterative cycle for a team involves three phases: Commit, Execute, and Evaluate.
Commit
The iterative cycle begins with the commit phase. As a team, we assess our current rate of throughput, our queue of work, and arrive at a projection of what we will have delivered by the end of our cycle interval.
The intended outcome is that the team exit the commit phase feeling confident that we have made the most informed commitment we can make based upon the information available to us at that time.
Solely relying upon the team’s throughput sets us up for disappointment. That average of how the last several cycles turned out is primarily a directional guide. We possess far more context at the start of a cycle than that. Is anyone on PTO? Are there any company-wide events? Are we launching a new and unknown service? Is there a critical live event for our product happening? Finally, what learnings and experiments from the last cycle are we bringing into this one? How does that inform or shape our commitment?
As a team, take a moment at the beginning of cycle planning to reflect upon all the variables affecting your capacity for scheduled work. As you pull new items into the cycle or review the body of work that your flow rate suggests, dialog across disciplines in the team to see if you’re aligned on how it’s going to be executed and whether the entire body of work is likely to be delivered.
Execute
If we are not careful, the execute phase can be seen as “just do the work.” Resist the temptation to stay heads down and not dialog about how execution is going. Execution is the ultimate test, where assumption meets implementation. The key outcome of the execute phase is to share what we are learning as we execute, and fold that learning into how we approach the remaining work in the cycle.
Each day of the cycle, team members are learning new information about the work in real time. What one individual has just learned could greatly affect how other team members should adjust how they’re approaching their work. Leverage the daily standup or huddle as a chance to sync on learnings that might not have been shared the day before, preferably toward the start of the workday, so that the team isn’t operating on stale information. If new discoveries are made during the day, share as soon as is feasible, don’t wait until the next morning.
The pressures and challenges of implementation can constrain us in ways that yield our best creative efforts. When we know what the possibilities of our current state offer, we are then free to pursue what can be done and cast aside worries about what we had hoped might be possible.
Evaluate
Every cycle affords us the opportunity to learn. The key outcome of the evaluate phase is to create space for the team that nurtures critical thought about team effectiveness.
Frame your cycle retrospectives not merely in terms of “what did we complete and not complete,” but rather “How did we do this cycle working as a team?” The work will certainly be discussed as the concrete examples of how we worked together, but let’s use those examples to see what is working well for us and what is not.
For those things that are not working, what could we try in the coming cycle to improve our approach? What is the evaluation criteria? What would we consider an improvement, and what would lead us to try a different experiment?
Take care to fold the learnings and experiments identified in the evaluate phase into the next cycle’s commit phase. Development logs are one great artifact for fostering continuity across cycles, but even an issue-centric Sprint or Kanban report is better than nothing. Failure to have the insights and experiments from our evaluation informing the next commitment erodes the meaningfulness of the evaluate phase for the team.
Conclusion
The iterative cycle of Commit, Execute, Evaluate applies whether our team is using a batch (Scrum, XP, variants) or a flow (Kanban, variants) system. The Commit and Evaluate phases of a flow system may not be as time consuming or explicit as they are in batch systems, but ensure that the intended outcome of each phase is being realized for the team.
For the person stewarding the team’s development process, mindfully observing the team members’ interactions is key; avoid the temptation to rely solely on the core artifacts of your system.