8. Moving all team members into a dedicated team room or team area does not cross-pollinate with cubicle assignments in the per-discipline-organized cubicle farm.

It's good to have engineers sit next to each other so they can work through solutions to problems. It's also good to have engineers sit next to content creators so the engineers can offer customer support for the custom authoring tools. It's somewhat of an inhibitor if a developer has to walk across the building multiple times per day to collaborate with another developer. Part of the problem here is that desks and cubicle walls are not moveable.

Lesson Learned: If you want collaboration to happen, don't mandate it first and then inhibit it at the same time. Instead first enable collaboration by removing the inhibitions, and then let collaboration happen by coincidence or out of necessity.

Best Practice: A way to make collaboration uninhibited is to first put desks on casters. Second, give everyone un-interruptible power supplies and wireless network connections. Next, consider getting rid of some of the cubicle walls. Team members are now enabled to unplug, and move their desks around the open bull-pen work area without shutting down and rebooting machines.

Thus a half day of face-to-face collaborative productivity is not inhibited by the hour it takes to move equipment, re-connect cables and reboot. Sure, un-interruptible power supplies for everyone are expensive. The hours of lost productivity, inhibited productivity, lost data, and damages from dropped equipment are also expensive.

Finally, tell developers it's urgent to get development tasks done on time and they can push their desks and computers anywhere they need to in order to get work done. The result is that developers will find it compelling to push their desks next to each other out of necessity to be productive, and not because of the mandate to fulfill the prophecy of buzzword project management.

For added comfort, each development team or development group can have a designated team area and moveable privacy screens and/or a team room. Make sure to provide big whiteboards on wheels too.

7. A team member says "I'm not doing something right now because I was told there needs to be a task entered into the backlog and the task needs to be assigned to me by the project manager."

Lesson Reinforced: The proactive person looks for the next task that needs doing, asks customers if everything is working, and thinks about what can be done now to make next month's to-do list lighter weight. The reactive person finished the work for the current two week sprint and believes they are not responsible for anything more until the next two week sprint when they are assigned more tasks.

Lesson Learned: Telling people that the whole team is focusing on only two weeks' worth of work at a time, and they can't work on tasks unless assigned, can make people reactive instead of proactive. It's important that all team members can see the big picture, and are encouraged to take responsibility for the components and details of the big picture without micromanagement.

Best Practice: Adding tasks to the Scrum spreadsheet feels like having to ask permission for things that have trivial granularity. Developers assume ownership and responsibility for the project. Developers have foresight about what work needs to be done next month. Developers are able to proactively work on tasks ahead of schedule as well as provide customer service to each other without needing a task assigned.

6. Start managing stories and sprints before all the people are on the team. Decide that your Scrum stories and sprints are 100% completed months before the project even has a QA tester.

Lesson Reinforced: Without QA in the first month of the project, you might as well admit that you are planning to have a death march and crunch time. It is common knowledge that adding QA to the project up front is not just important, it's mission critical.

Best Practice: Throughout the development cycle, have engineers and content creators fix bugs as they go, so that the total open bug count stays at a minimum. Have QA on the project at the beginning of the development cycle to report bugs and to verify and close bugs. This is important for reducing crunch time due to overwhelming number of bugs at the end of a development cycle.

Every day, each developer can look at the open defect count and their own current dev task to do list. If there are more open defects than dev tasks, consider the bug count too high and spend part of the day fixing the lowest hanging fruit before switching to the next dev task.

Even better: each person on the team is customer-friendly and asks their customers and teammates if there are any issues that are preventing them from fixing their own bugs. Recognize that some bugs don't get fixed because they have dependencies on other people fixing other bugs.