Difference between revisions of "Daily scrum of scrums"

From Pearl Language
Jump to navigation Jump to search
m (Agile)
(Embellished.)
Line 5: Line 5:
|wish in a single line=Need communication to flow between connected teams.
|wish in a single line=Need communication to flow between connected teams.
|therefore in a single line=Let one or more team members from each team have a short, daily meeting.
|therefore in a single line=Let one or more team members from each team have a short, daily meeting.
|wish=Independent teams can work very efficient, but can be isolated from the rest of the organization. We need the communication to flow between teams.
|wish=Independent teams can work very efficient, but can be isolated from the rest of the organization. We need the communication to flow between teams, effectively resolve any dependancies, and integrate. Working {{p|trunk only}} increases this need.
|background=You need to coordinate teams on a daily basis.
|background=You need to coordinate multiple teams on a daily basis. The {{p|scrum of scrums}}:
*The primary means of synchronizing multiple teams during sprints
*is the primary means of synchronizing multiple teams during {{p|sprint}}s;
*Ideally daily, after the individual team’s {{p|daily scrum}}, but 2–3 times a week is often acceptable
*is Ideally done on a daily basis, shortly after the individual team’s {{p|daily scrum}}; often, 2–3 times a week is acceptable;
*Representative from each {{p|development team}}—not necessarily the {{p|scrum master}}—the {{p|development team}} decides dependent on the subject matter.
*is held by qualified representatives from each {{p|development team}}—not necessarily the {{p|scrum master}}—the {{p|development team}} decides dependent on the subject matter;
*Three main questions:
*addresses these main questions:
*#What has the team done since the last meeting?
*#What have we completed since our last meeting?
*#What will the team do until the next meeting?
*#What will will we complete before next meeting that we know will speed us up, and how do we know we have completed it (a.k.a. ''How to demo?'')?
*#What impediments does the team have that need to be escalated (i.e. that cannot be efficiently removed at the team level)?
*#What impediments are in our way that we cannot tackle ourselves and need to be escalated?
*Additional question:
*#Will anything that we do create an impediment elsewhere (e.g. perform a large integration or fail to satisfy a dependency)?
**Is the team about to do some that will create an impediment for another team (e.g. perform a large integration or fail to satisfy a dependency)?
 
*Track results in the {{p|scrum of scrums}} impediment log.
Excel, and:
*Logs and tracks issues that have been escalated to the {{p|scrum of scrums}}.
*address issues then and there, since all qualified people are present; i.e., unlike the {{p|daily scrum}}, do not postpone tackling the issue until after the meeting;
|therefore=Let one or more team members from each team have a short, daily meeting.
*track items in the {{p|scrum of scrums}} journal, including the escalations;
*consider maintaining a separate backlog or even {{p|story map}} for the {{p|scrum of scrums}}; and
*adopt {{p|daily clean code}} and aim to fix all detected bugs within the same day and do not enter the bug tracking system.
 
Just like the {{p|daily scrum}}, timebox the {{p|scrum of scrums}} to 15 minutes.
|therefore=Let one or more qualified team members from each {{p|development team}} have a short, daily meeting.
|new=One level only—avoid a ‘Scrum of Scrums of Scrums of Scrums’.
|new=One level only—avoid a ‘Scrum of Scrums of Scrums of Scrums’.
}}
}}


{{Source}}
{{Source}}

Revision as of 08:16, 7 September 2012

…Several teams work on the same product.

✣  ✣  ✣

{{{wish full}}}

You need to coordinate multiple teams on a daily basis. The scrum of scrums:

  • is the primary means of synchronizing multiple teams during sprints;
  • is Ideally done on a daily basis, shortly after the individual team’s daily scrum; often, 2–3 times a week is acceptable;
  • is held by qualified representatives from each development team—not necessarily the scrum master—the development team decides dependent on the subject matter;
  • addresses these main questions:
    1. What have we completed since our last meeting?
    2. What will will we complete before next meeting that we know will speed us up, and how do we know we have completed it (a.k.a. How to demo?)?
    3. What impediments are in our way that we cannot tackle ourselves and need to be escalated?
    4. Will anything that we do create an impediment elsewhere (e.g. perform a large integration or fail to satisfy a dependency)?

Excel, and:

  • address issues then and there, since all qualified people are present; i.e., unlike the daily scrum, do not postpone tackling the issue until after the meeting;
  • track items in the scrum of scrums journal, including the escalations;
  • consider maintaining a separate backlog or even story map for the scrum of scrums; and
  • adopt daily clean code and aim to fix all detected bugs within the same day and do not enter the bug tracking system.

Just like the daily scrum, timebox the scrum of scrums to 15 minutes.

Therefore:

{{{therefore full}}}

✣  ✣  ✣

One level only—avoid a ‘Scrum of Scrums of Scrums of Scrums’.


✣  ✣  ✣

[[wish::Independent teams can work very efficient, but can be isolated from the rest of the organization. We need the communication to flow between teams, effectively resolve any dependancies, and integrate. Working trunk only increases this need.|]]