Planning Process Communication

Background

During the first half spring semester, our team was following a continuation of our fall planning process. Milestones were assigned to milestone-owners at the planning meeting, along with budgeted time, and then it was the milestone-owners' responsibility to make sure that the milestones is completed at the end of the iteration.

There were several issues with this process:

1. The milestone owners were supposed to give out the tasks for the milestones, but they felt responsible for the tasks, and so owners tried to finish up milestones by themselves.
2. Since there was no team-review of tasks, the milestone owners often did not specify tasks in adequate detail. So even when other team members wanted to help out, they did not have enough detail about the tasks.
3. Lack of detail contributed to bad estimates on the milestones, and so each iteration, most of the milestones would not get done. As a result, the team was getting demoralized(Finishing makes people happy).

At that time, right before Spring break, Michael suggested that we should try something scrum-like.


Creating the process


With Michael's suggestion and a Scrum book from Marco, I wrote up our Spring planning and tracking process that galvanized the team, organized the team's work, and brought happiness to the world. No, actually, this process raised another issue, but I'll talk about that in the next section.
As you may see from this process, the key points of it were these:

1. Milestones still had owners, but the owner's responsibility was to adequately specify tasks before theplanning meeting, and not afterwards. These tasks would create the product backlog.
2. The team sat down together and decided on the milestone and task priorities, and then take tasks from the backlog according to the priorities.
3. The team-lead's job was to make sure overhead tasks were also included in the individual backlogs. At the end of the planning meeting, no team member was supposed to have more than 12 hours of tasks.

After writing down the process, I emailed it out to the team, and then reviewed it at our weekly status meeting. The team seemed to generally like it.

Implementation

However, after Spring break, when we came back to implement the process, we found there were significant gaps in the team's understanding of the process. It was clear that we all had different interpretations of the process, even though it was written down and crystal clear(to me at least).

That was when we had to forget our previous reviews of the process, and just work it out face to face with the team. We tried out each stage of the process, and adjusted it according our needs. We prioritized milestones, and then went off to detail tasks, and then came back to take those tasks according to milestone-priorities.

At the end of that 5 hour long exercise, we had our first product backlog and individual tasks that we were responsible for. Since everyone had tasks that they had voluntarily taken, the milestone owners were not burdened with distributing tasks. And everyone knew the milestone priorities. Therefore, the most important milestones were guaranteed to finish.

I learned a big lesson from that meeting. It does not matter how eloquently you write down something. It does not matter how emphatically your team nods their heads when you ask if they understood it. Only when the team can work through the process together and feel confident about it, can it say that it understood a process.

Conclusion

The result of all this effort was a happy ending after all. In summer, the team added some additional checkpoints to this to make sure tasks are being specified correctly and completely, and added a client-prioritization step. However, the underlying process stayed the same.
The key takeaways from this were:

1. Critical processes such as planning and tracking needs to be communicated. And sometimes you have to sit with your team in a 3 hour meeting for that communication to happen.


2. Prioritizing milestones together with the team really helps to get team buy-in on the importance of those milestones
.

3. Since the team members were taking tasks, they felt more responsible for them than before