The Scrum Training Series is provided free of charge by CollabNet, Inc. and used by thousands of Agile practitioners, coaches, and trainers around the world.
Contact Michael James via Twitter.
Script without illustrations.
Every day at the same time and place, the Scrum Development Team members spend a total of 15 minutes reporting to each other. Each team member summarizes what he did the previous day, what he will do today, and what impediments he faces.
Standing up at the Daily Scrum will help keep it short. Topics that require additional attention may be discussed by whomever is interested after every team member has reported.
The team may find it useful to maintain a current Sprint Task List, a Sprint Burndown Chart, and an Impediments List. During Sprint execution it is common to discover additional tasks necessary to achieve the Sprint goals. Impediments caused by issues beyond the team’s control are considered organizational impediments.
The Daily Scrum is intended to disrupt old habits of working separately. Members should remain vigilant for signs of the old approach. For example, looking only at the Scrum Master when speaking is one symptom that the team hasn’t learned to operate as a self-organizing entity.
Q: Why should the Product Owner attend the Daily Scrum?
A: This question is inconsistent with the current Scrum Guide. According to the Scrum Guide, the Scrum Master enforces the rule that only the development team participates in the Daily Scrum. See the section above about why this question is based on a flawed assumption. If we're serious about team self organization (remember principles before practices), inviting the Product Owner to the standup is a Team and Product Owner decision. The Intel case study found their teams did better work when they didn't invite the Product Owners, due to years of command and control habits (see the thumbs down for "PO on the Team" on page 10). All of the answer choices are probably wrong so I guess you'll have to pick the one that sounds the least like traditional command and control.
During Sprint execution, team members develop an intrinsic interest in shared goals and learn to manage each other to achieve them. The natural human tendency to be accountable to a peer group contradicts years of habit for workers. Allowing a team to become self-propelled, rather than manipulated through extrinsic punishments and rewards, contradicts years of habit for some managers. The Scrum Master’s observation and persuasion skills increase the probability of success, despite the initial discomfort.
Self-organizing teams can radically outperform larger, traditionally managed teams. Family-sized groups naturally self-organize when the right conditions are met:
Psychologist Bruce Tuckman describes stages of group development as “forming, storming, norming, performing.” Optimal self-organization takes time. The team may perform worse during early iterations than it would have performed as a traditionally managed working group.
Heterogeneous teams outperform homogeneous teams at complex work. They also experience more conflict. Disagreements are normal and healthy on an engaged team; team performance will be determined by how well the team handles these conflicts.
Bad apple theory suggests that a single negative individual (“withholding effort from the group, expressing negative affect, or violating important interpersonal norms”) can disproportionately reduce the performance of an entire group. Such individuals are rare, but their impact is magnified by a team’s reluctance to remove them. This can be partly mitigated by giving teams greater influence over who joins them.
Other individuals who underperform in a boss/worker situation (due to being under-challenged or micromanaged) will shine on a Scrum team.
Self-organization is hampered by conditions such as geographic distribution, boss/worker dynamics, part-time team members, and interruptions unrelated to Sprint goals. Most teams will benefit from a full-time Scrum Master who works hard to mitigate these kinds of impediments.
While Scrum does not prescribe specific engineering practices, Scrum Masters are responsible for promoting increased rigor in the definition of done. Items that are called “done” should stay done. Automated regression testing prevents vampire stories that leap out of the grave. Design, architecture, and infrastructure must emerge over time, subject to continuous reconsideration and refinement, instead of being “finalized” at the beginning, when we know nothing.
The Scrum Master can inspire the team to learn engineering practices associated with XP: Continuous Integration (continuous automated testing), Test-Driven Development (TDD), constant merciless refactoring, pair programming, frequent check-ins, etc. Informed application of these practices prevents technical debt [high cost of future change --mj].