9. Interrupt what people are doing to have them come to the daily 15 minute stand up meeting.

Schedule the daily 15 minute stand up meeting on everyone's Outlook calendar with a 15 minute reminder, and then the ScrumMaster shows up 2 minutes late and politely waits for those team members who show up 10 minutes late to the meeting.

Question: How does a 6 month project get a whole year behind schedule? Even if you haven't read the book Mythical Man Month, it is common knowledge that the answer is one day at a time. The 15 minute daily huddles are not more important than contiguous hours of concentration and in-the-zone productivity.

Interrupting programmers, a.k.a. "committed pigs" of Scrum, in the middle of something technical, just to make them come to the team room only to ask them "Are you blocked?" is a good way to derail a half day's worth of work as well as derail the entire project. Every day the conversation might go like this:

ScrumMaster: "Are you blocked?"

Engineer: "No, we were just working on making the widgets slide across the screen smoothly by using the first Hermite basis function to interpolate an 'S' shape curve."

ScrumMaster: "Since I'm a non-technical person why don't you say that in English?"

Engineer: "The UI will look cool with smooth animation."

ScrumMaster: "Do you have an estimate for that?"

Engineer: "Tomorrow."

Lesson Learned: The 15 minute daily stand up meeting was supposed to ensure that team members do not spend a day getting sidetracked by tasks that are not important to shipping the product. What if, before there was Scrum, developers had already been through a couple development cycles on various projects and had an established track record of working on the correct tasks and shipping products on time? How does the 15 minute daily meeting correct something that wasn't broken? It doesn't.

Lesson Learned: A 15 minute reminder for a meeting that starts 10 minutes late just wasted 25 minutes of time for everyone on the team. Suppose that after the meeting developers go back to their desks and spend an additional five to 15 minutes to concentrate and focus on what they were doing before the meeting. The time around a 15 minute meeting adds up to about 40 minutes of distractions during an eight hour work day.

This can amount to weeks of man hours in the course of the development cycle. The question here is: was this time well spent? Does this daily meeting accomplish what it is supposed to accomplish, and does the benefit outweigh the cost? Is there a better way to accomplish the same thing, and without consuming the time?

Having the backlog in an Excel spreadsheet separate from the bug database just makes more work for everyone to maintain a to do list in two separate tools. It's obvious that development tasks and defects both have the same kind of data. In other words, database software does not know the difference between a dev task and a defect.

The only difference between a dev task and a defect is that a dev task comes before implementation and a defect is after implementation and includes steps to reproduce it. There should be no reason why dev tasks and defects can not be tracked with the same database, project management tool.

Best Practice: Some development tasks take a couple minutes to complete and some development tasks can take multiple days to complete. Instead of having the same conversation everyday with a Scrum Master, it would be better to put all tasks in a task management database.

The task database needs to have some kind of folder or query mechanism to view which tasks are being worked on today. Each person on the team can have their own folders and the folders can be called "WorkComplete", "WorkInProgress" and "WorkToDoNext". Each team member updates their own folders as they are switching tasks, and when they claim complete on a development task or claim fixed on a bug.

Everyone on the team, from their own machine, can see everyone else's folders, so they can see what other team members are working on. The time estimates or time remaining can also be entered into each task item. If anyone wants to know what team members are doing today, that person can just look at the "WorkInProgress" folders. TestTrack, DevTrack and FogBugz are three commercial off-the-shelf defect-tracking and project-management database tools that have features that can support this.

If you find value in visualizing the Scrum task board or if you still use a Gant chart, consider making a little graphics program that takes everyone's folders and tasks from the database and renders the tasks as nodes (like task cards on the Scrum board) in a directed acyclic graph of task dependencies on a horizontal axis time-line (like a Gant chart).

Then you can use a projector to display the rending on a wall. Imagine you can add little progress-status bars on each task for the hours estimated and hours remaining (like health bars above avatars). You can even have animated effects for when team members are at their desks claiming complete on tasks (like the animation of files going into the recycle bin in Windows Explorer).

Imagine these animated effects will look like a fireworks particle system when you reach 100 developers on a team. Developers whose actual hours closely match estimated hours will receive +3 experience points and completing a cycle will allow them to level up. W00t! Executives will be so entertained to have the real-time visualization of teamwork and productivity that they will forget to play-test the latest build of the game.

Best of all, this electronic Scrum board will scale from small teams of 5 game developers to large teams of 250 game developers. Don't forget to implement smooth-zooming to hyperbolic fish-eye view for large graph visualization (see Google images for those words).