5. Scrum Pitfall: The 15-minute daily stand-up meeting degenerates into a daily go-around-the-table-and-each-person-give-a-status-report.

There are no action items from the daily meeting and the daily meeting doesn't actually help increase productivity. At the daily meeting, the Scrum Master makes some remark that team members or the team's actions are "not Agile".

Lesson Learned: There is no value or purpose in practicing Scrum just for Scrum's sake.

Lesson Reinforced: "Round table status report without action item" meetings are a waste of time. Certainly the cost of everyone else's time combined does not outweigh the benefit of saving the meeting inviter's time.

Best Practice: Maximizing everyone's 40 hour a week bandwidth pipe is more important than a daily 15 minute meeting. If one person on the team has the lion's share of work to do and others are waiting for the next daily build or the next two week sprint there is something wrong with the project or the project management. The workload needs to be evenly distributed.

Best Practice: Make sure all meetings have an agenda, and the agenda is part of the meeting invite. An action item includes the task that will be performed, the name of the person who will do the task and should also have a deadline or at least a time frame. For example: "Joe will have placeholders for the character model checked into source control by the end of the day tomorrow, so designers and engineers can work with it this week."

If there were no action items for anyone after the meeting, there was no purpose to having developers stop working and gather into a conference room. Status reports and other communication can be done over email, instant message or a phone call.

4. Make Scrum mandatory.

Stakeholders and executives make Scrum mandatory for the development team and expect quantitative project completion predictions. Managers don't ever provide feedback to the team members, or reveal what value was actually gained from all those Scrum sizing exercises where developers choose numbers from a deck of cards.

Even worse: executives don't gain any value at all from the quantitative predictions that they didn't already have with the project manager's gut feeling. Or maybe the executives don't understand that the team members are spending time doing ridiculous number guessing exercises to size a Scrum story in order to obtain the quantitative prediction that no one looks at.

Lesson Learned: Communication needs to go both directions, not just one direction. That means up the chain of command and also down. Feedback from, and visibility of stakeholders and executives is equally important as providing those stakeholders with a summary of the project status.

Best Practice: If a milestone is completed on time or if a game ships on time, stakeholders, senior management, and even executives walk around the cubicles and say to individual team members at the bottom of the org chart some things like "Hey, I heard your team completed its milestone on time and your project is on schedule, great job! That's exactly what we like at this company! That's excellent work!"

The positive reinforcement from the top of the org chart is worth more than any gold that anyone can earn in any MMO. Note to management and executives: if you want productivity increased, make sure your positive words are more valuable and more gratifying to employees than their time spent shooting giant zombie spiders and leveling up.

Imagine if there is just one milestone that is on time and that on-time delivery gets personalized recognition and reward by both the VP of product development and also by that VP of marketing who never seems to come out of his/her 700 square foot corner office for anything. Compare that to the same on-time milestone when no one seems to notice or care about the hard work that went into it. Success breeds more success! Low morale breeds high-cost employee turnover.

3. Implement only two weeks' worth of work and write only the code based on what you currently know about the game design.

If you were not assigned to work on a task, then you can't work on it. Ignore any concern that the game design may change later on in the development cycle.

Lesson Reinforced: Bottom-up code design is not better than top-down code design. Scrum, Agile, and Extreme Programming cultivate and promote bottom-up code design. When there is lack of big picture design documentation, the tendency is to implement one thing at a time, and then modify and tweak according to customer's feedback.

Since there isn't any foresight about what code will get shipped and what code will be thrown away due to design changes there isn't a lot of care taken to make code maintainable. Adding features that were not planned for can be costly. Down the road band-aids and patches require time spent refactoring.

Best Practice: Make a game from low fidelity to high fidelity. The low fidelity version has prototypes of all the features. Code can be organized from top down and with understanding of all the features that are going into the product that is going to ship. Note that there is a difference between code and content. Perhaps the game content is what you want to be able to sprint and iterate on.