The Rally Coach's Corner
The Daily Stand-Up
The first and most basic rhythm of the Agile feedback cycle is the daily standup. It's just what it sounds like - a daily meeting where everyone stands up for the duration of the meeting. When I give Agile workshops, one of the questions I'm often asked is how to do daily standups when the teams are geographically dispersed. While this can be a challenge to coordinate and maintain, you'll soon find that the benefits of the daily communication make it well worth the effort. Here are several options to consider with your team:
Answering these questions gives everyone immediate visibility into the status of the iteration, helps to prevent misunderstandings, and practically eliminates ninth-hour surprises. When I give workshops, one of the questions I’m most often asked is how to do daily standups when the teams are geographically dispersed. While this can be a challenge to coordinate and maintain, you’ll soon find that the benefits of the daily communication make it worth the effort. There are several options to consider with your team: The standup not only provides a daily forum for status updates, but brings problems immediately into focus so teams respond successfully to fast-changing project realities. Within “workday” time zones: If the team members are within eight hours of each other, the team should determine the best time of day to hold their standups. For example, a daily conference call could be scheduled at 8am Pacific time, which would allow other team members in the Mountain, Central, and Eastern time zones to dial in and participate at 9am, 10am, and 11am respectively. Beyond an 8-hour time difference: When it becomes unreasonable to have all team members attend the same meeting, have multiple standups. Try to keep the number of standups limited, as there still needs to be coordination and communication among the geographically dispersed teams. This communication can take several different forms:
The practice of the daily standup not only provides a forum for regular status updates, but brings problems immediately into focus for quick action. It’s this fast feedback that helps the teams react to change successfully, and makes it imperative that the daily standup be one of the first essential “heartbeats,” or rhythms, that any Agile team establish, regardless of office locations. » Post your comments and questions on this article Tracking in the Agile Project, or How to Let Go of Task Completion Dates
Often, I am confronted with questions from clients and colleagues about task-level and resource-level tracking in Agile software development projects. Specifically, I receive requests to add "Estimated/Required Complete Date" to iteration tasks managed in our Rally tool. This tells me that there is still confusion and fear around letting go of plan-driven approaches shown to cause more harm than good. Project managers new to Agile approaches often feel they must still track the lowest possible level of dependency in order to define "criticality"; that is, for any given task, and the individual assigned to the task, what is the estimated completion date versus the current expected completion date for that task? The assumption is that answering such questions identifies a "Critical Path" of dependencies that can be used to either push delivery dates out or pull them in based on how they re-allocate resources and revise estimates. This is such a slippery slope on which to stretch our legs despite a desire to nurture traditional software teams through their Agile transition by giving them little plan-driven hooks that help maintain their equilibrium. Classically, estimating time to task completion requires tracking the estimated and actual start times; the estimated and actual number of resources assigned; and the estimated resource availability - all at the task level! This sets in motion a risk management strategy that relies on detailed tracking of each individual resource and their estimates of how much they think they have completed. But as Eliyahu Goldratt illuminates in his two books "The Goal" and "Critical Chain", such tracking often leads to sub-optimization of processes and unintended consequences. Teams that focus on "the trees" of how they are doing compared to their estimated completion dates inadvertently build in slop at the task level and sadly lose track of the "forest" of completing the highest priority objectives of the release. ...in Agile projects we measure how much effort remains to reach completion, not the estimated dates of completion. We remove measures of the individual and instead measure the success of the release. For this reason, the only times that are tracked in Agile development projects are the fixed start and end dates of the time boxes - the iterations or sprints - and the release date. We manage iteration stories only by their priority. We measure the status of tasks within a story only in terms of "How much work is left to do," and "Is the work being blocked in any way?" Tracking percent done and estimated completion date does not contribute usefully to either of these measures. As Goldratt and others have discovered, the only measure that matters is having all components delivered in time to accept the release. Additionally, as Rob Austin from the Harvard Business School will tell you, adding more measures to processes only sours individual performance, not enhance or encourage it. So while all of this may seem like fluffy theory to some, these discoveries lie at the heart of why the Agile movement has risen out of the traditional plan-driven world to streamline what we track in Agile development projects so we can dramatically reduce the cost of change. We all agree that there is still a need to estimate, with some level of confidence, how much functionality we can deliver within our time box. Therefore, in applying critical chain scheduling to Agile projects, we track how much we accomplish from iteration to iteration, and compare that to our estimates from the iteration planning meeting. We manage the unpredictable by focusing on the highest priorities first and aggressively remove blocks that stall our progress. We also can add a buffer iteration at the end of the release to allow all processes and tasks to catch up to one another. So in summary, in Agile projects we measure how much effort remains to reach completion, not the estimated dates of completion. We remove measures of the individual and instead measure the success of the release. We buffer the release with a time box for catching up rather than estimate the exact dates of when functions should progress through their lifecycle. And we react to changes that occur rather than measure success by how well we adhered to a detailed plan. » Post your comments and questions on this article For further reading, consider:
|
1050 Walnut St. Suite 202, Boulder, CO 80302 : 1-866-348-1552