Science Fair

I'm at my company's annual kickoff this week. One of the things we do that is always interesting is Science Fair. Everyone has the opportunity to build a project, something they think our software can do that currently isn't in the roadmap. There have been some projects from past years that have made their way into the product. It's a good way to take advantage of people's intrinsic motivation.

I just finished the book Drive, by Daniel Pink. The book focuses on motivation. In the book, the author talks about other companies that do something similar. At Google, people get to spend 20% of their time on projects they want to. Many of these have made it to products. Atlasian software has "FedEx Day" where people are given 24 hours to come up with something, so called because people must deliver overnight (Side note - Atlasian's Jira tool came out as one of the top agile tools in VersionOne's 2009 State of Agile Development survey).

People get intrinsic motivation through autonomy, mastery, and purpose according to Daniel Pink. Autonomy is getting to choose what, when, and with whom they work with. In our science fair, people get to work on teams if they chose. Mastery is getting good at what you do, through such things as "Goldilocks tasks" that are hard enough to challenge but not so hard as to seem impossible. The purpose is why the company exists, something that everyone should relate to.

These intrinsic motivators will drive people and organizations much more effectively than the old carrot and stick approach, which we're all used to...if I hit my utilization target, I get a bonus. The carrot and stick can backfire in a number of ways, including stifling creativity. Things like FedEx Days or Science fair, on the other hand, will bring out creativity in a group of knowledge workers, leading to new products or services. So what's your organization doing to promote creativity?

More is not better

Have you ever been on a project that is falling behind, so someone up the food chain decides you need more people and then you fall even farther behind?

One reason for this has to do with communications. The more people you have on a project, the more communications channels you have. Two people, one channel...10 people, 45 channels. Agile works because you keep the teams small and keep everyone in the same room (ideally), minimizing the amount of communications you need.

Joel Spolsky recently wrote an article in Inc on this topic. He mentions the team responsible for the main menu for Vista at Microsoft, 43 people in all, or 903 communcations channels. In a year, only 200 lines of code were written because so much time was spent coordinating.

So what do you do? Think more about your communications. Don't invite people to meetings who don't need to be there. Don't send email to large distribution lists. Take a little more time planning your communications instead of blasting it out to people just to keep them in the loop.

Requirements

I had a requirements document sent to me this week to review. It was a piece of art! The document was about 100 pages long. It was prepared about 3 years ago and has sat on a shelf until now. Now it's time to start planning the project.

The first step was to ignore most of the document. My approach to move forward will be to look at the high-level business process and come up with a rough estimate on how big the project is. Then my team will engage the process owners to start drilling down into the requirements as we start building the process. We'll have regular reviews, and probably in 2-3 months, we'll have the process ready to deploy.

I think of how much waste went into this document. First, there was the time to try to document everything. In all likelyhood, a lot of what was documented doesn't really need to be in the final system. Then the document sat and gathered dust. Any Lean advocate will tell you to avoid work in progress. Regardless of how the requirements were being captured, it shouldn't have been done until everyone was ready to start on the project. Finally, there was my time trying to read/understand the requirements. As typical, it was written standard requirements-speak "the system shall provide the capability to..." and then followed by use cases that provided the same information in a more confusing manner. I could probably summarize the whole thing in a dozen user stories.

I'd like to start a reality show like "What not to Wear" expect about project management. Each week it would look at a different project and help get the project moving in the right direction. I'll have to think of a good name.

Burndown Charts and Student Syndrome

I have a client that has a tendency to get nervous about half way through each iteration because the burndown chart isn't tracking. Each member of the team is giving a daily estimate of how much work remains. The catch is, each one is accounting for some uncertainty in testing/integration, so they are padding their estimates with a buffer.

The problem with the buffers can happen in agile or waterfall projects. I can remember the old days of project management...I would be working on the schedule. I'd go to the various team members and ask them how long their tasks would take. They would add in a "fudge factor" to account for any uncertainty. Then when it came time to do the work, they would procrastinate on starting, knowing this buffer was there. However, when they did start (later than they should have), they would come across the uncertainty and now their buffer was gone and the project got behind schedule. This phenomenon was referred to by Eliyahu Goldratt as Student Syndrome.

The trick of course is not to put the buffer into each estimate in the first place. In my client's case, what has happened over the last couple interations is that all of a sudden at the end of the iteration, everyone gets their work done, doesn't need the extra buffer, and the burndown takes a sharp nosedive. The only real issue is that the PM taking unnecessary steps during the iteration to try to fix a problem that doesn't exist (and try to explain what is happening to management).