Thursday, May 7, 2009

The power of ownership

I happen to be working simultaneously on two projects at the same time. One is a close to a classic project with a project manager, a MS project plan and the traditional dynamics between a project manager and the resources working on the project. The other is a team that is taking a more agile approach with user stories and sprints and so on. This provides a real interesting learning opportunity to contrast the different approaches to getting things done.

It is a bit of an apples to oranges comparison, today I was really struck with an benefit for the agile approach that haven't really appreciated. On the classic project there is a distance or an understanding gap between the formal project plan and the people doing the work. On the classic project many people just don't have the time or care to become familiar with the schedule or the project plan. If they do, they are primarily just looking at the end date and maybe what is on the critical path to the end date. It is a project manager's job to drive the planning process and make the team aware of what is in the project plan. But most of the time they really don't care beyond the success of the project. They have developed some kind of understanding what what needs to be done and that's what drives them. Especially in a matrix organization, the project manager is often some one running ahead of or along side the project trying to keep the plan aligned with the reality of the performing team. In a matrix organization the resource manager will have language and vocabulary for talking about what needs to be done, it should be but it is often not exactly how it is described in the project plan. A good project manager will have some standards for describing tasks or doing the work brake down structure. This may be very professional and orderly but it is often not how the resources would typically describe the work to be done. IOn top of the semanict and vocablary issues the plan may be captured in a tool that not every person has due to license cost or just convenience. Consider a team of 12 where on the only the project manager and the resource manager have a tool like MS Proejct Professional and their dest top. The other 10 on the project get PDF reports, PWA access, or get to watch the project manager use an overhead projector to display the plan on the wall.

Some resources may passively resist the regimentation and structure that comes from working on a formal plan maintained by a professional project manager . I believe that all of these factors contribute to the gap between the plan and the resources.

On an agile team we have user stories that are written by a variety of people on the team. There is a template "As a I'd like so that " People tend to more or less follow the template but for the most part it is written in their own words or at least there is a more level or democratic opportunity for someone to edit the user story before it is agreed to and acted upon. If the team has tasks related to the implementation of the user story it is very likely that the tasks are written by the person performing the work. They may use a tool designed for agile teams, a Sharepoint list, sticky notes or a spread sheet. Key is that all team members are more often in the same position when it come to tools used to author the user stories or tasks. This seemingly more chaotic way of specifying what needs to get done does have it's draw backs. The big one is that we may miss and important piece of work that needs to get done due to the lack of uniformity in the specification and assumptions among the multiple people contributing to the tasks and user story definitions. We try to mitigate that risk by review and discussion of the user story list that doesn't happen as often as it should.

So in the end there are two alternatives each with their Achilles heal. A coherent professionaly maintained work break down structure that is some what distant to the resources doing the work. Or, a more chaotic structure that the resources doing the work readily understand. Generally I prefer the latter. I'd rather have a looser "plan" with inconsistnecies that people really follow than a really tight comprehensive plan that people doing the work have not internalized or even do not readily understand. In the end it is the outcome of the project that matters. On top of just understanding, there is the ownership issue. By far and away I believe that people work harder when they feel they own the plan and they have personally contributed to its creation. This ownership feeling is fosterd much more when they actually press the keys that make the plan artifact what ever form it happens to take. A perfect plan can never be achieved, however a team fully comitted to a successful out come is much more valuable than a perfect plan. In the end it is the outcome that matters. I'll trade almost every thing to get a team that owns the plan.