How do you evaluate you process? It is effective and efficient. George Dinwiddie has created a process evaluation kit:
How long does it take an idea to be realized and deployed? A year? A month? A week?
What keeps it from being shorter? Budget cycles? Serial processes? Too much work? Bottlenecks?
How do you tell that you’re working on today’s highest priority items?
How do you verify that the systems you’re developing are solving the intended problem? How quickly do you know?
How do you measure progress of system development? Is this a measure of something you actually want, or is it a surrogate measure? Is it a reliable progress indicator or does it hide surprises?
As a Scrum Master you have to really listen to what the guys in the team are presenting. Some impediments are explicitly mentioned, but others may be hidden “between the lines”. The team member may not actually discovered the impediment yet. It is easier if you have a checklist of impediment categories that you could have in your back head during the Daily Scrum.
Tom Perrys talks about this in a presentation “Impediment Hunting” at Agile Roots 2009 conference.
He identifies a number of Impediment Categories:
Incomplete Work
Missing Information
Missing Parts
Repeated Work
Waiting
Missing Dependency
Not Enough Time
Interruptions
Defects
Bureaucracy
Mis-Communication
Decisions Not Made
This list of categories can be used as a checklist be the Scrum Master during the Daily Scrum.
He also adds a fourth question:
What one thing helped to accelerate my progress yesterday?
Daily Scrum is not only about that you as a team member presenting your status and possible impediments. When the other guys are talking it is equally important that you practice active listening. You should really listen to what they are saying and also what they not mention. Remember that you are in the same team working together towards the same goal.
Boris Gloger has improved the Daily Scrum with an additional question:
In the last couple of month I developed a 4 questions that every team member shall have in his mind while listening to the other team member:
How can I help you doing your job!
This 4th question will help you to run better and more productive Daily Scrums.
When I teach Scrum for beginners I sometimes get the question “Why standing up?”. There are a number of good reasons why we should stand up during the Daily Scrum. Mark Levison has summarized these in a good post:
Standing
Nobody wants to stand for very long – keeps the meeting short
We’re away from our computers so there are fewer distractions
We stand in a semi-circle and face the task board
Keeps the conversation focused on the tasks and helps us to keep from drifting off track
Helps us avoid reporting to a leader – instead we’re reporting to the rest of the team
Standing can be done in the team area and doesn’t require a meeting room – this helps stay in the context of our work.
Standing feels like it keeps the energy level up
Sitting
Some people become distracted and read email etc.
Other Best practices
No cell phones, checking email on Crackberries
No side conversations
Only people with skin in the game (or tasks to complete) may talk, others may attend but listen quietly
The meeting should be held at the earliest moment people are able to attend every day. Some people wait until the daily scrum is held to start work.
Time boxed the meeting should last at most 15 minutes.
Not in the office: call in or email your status in (weaker because you don’t know what the rest of the team is doing).
One of the most important points that I see that gets missed: The standup is about reporting to the rest of the team, not the ScrumMaster or Manager.
But as with anything in Scrum try all the variations and discuss the results in the next retrospective.
Daily Scrum is a powerful tool and brings impressive results.
The daily scrum has done some impressive things. It has:
Shown the real team. The people who really aren’t committed don’t bother to come to a brief, daily meeting. It’s very clear who the people doing the work are.
Increased collaboration. The area experts have become known, and people ask them questions.
Sped the project. Issues that would have delayed people for days are now resolved much faster.
Not bad for a meeting that lasts no more than fifteen minutes.
The regular Scrum-of-scrums is a good initial approach to handle communication between the sub-teams. However, this is not enough. A large team will probably need several coordination virtual sub-teams (forums):
Impediment and progress coordination team. This is the plain scrum-of-scrums.
Technical and Architecture coordination team. During these meetings technical dependencies and impediments are resolved.
Integration team. This team is responsible for integration of all sub-teams results into a a single product.
Product Owner team. All Product Owners from the sub-teams and Master Product Owner.
This is not new or unique to agile teams in any way. Large projects I worked in before the Agile era all had these types of coordination. The difference is that these coordination meetings or product integration will occur more often than in waterfall projects.
This approach is described by multiple people and blogs. Paulo Caroli writes:
We changed the SoS format. At this stage, we broke it into several SoSs: The PM SoS, the Dev SoS and the QA SoS. In fact the PM SoS called was named SoS: Scrum of Scrums. The Devs and QAs meetings had other names such as Dev hurdle and QA catch up. The PMs kept the SoS in a daily basis; the other roles varied the frequency of their catch up meetings.
The SoS became a PM update, but it was an essential (and quick) PM update. Actually, the SoS still kept the stand-up in circle format, which prevented the PMs form giving long updates (specially after standing up in each team stand up, and then in the SoS). Also the PMs were still focusing on answering the original 4 questions of the SoS
Mike Cottmeyer presents his approach how to scale Scrum and how you might have different types of scrum-of-scrums in Leading Agile: Scrum of Scrums.
Mike also presents his ideas in this video:
Bruno Collet presents a similar approach:
The organizational paradigms consist essentially in setting up one or more additional teams to deal with the issues mentioned above. These additional teams are:
Customer Oriented Software Development 