Monday, December 12, 2005

Gimme a Date

I have been in the role of project manager for about 5 months now. One phrase I find myself repeating is "So, do you have a date when that will be done..." I used to hate to have to provide dates for things I barely understood. I felt that anyone who asked was obviously clueless. Now I find myself on the other side of this question...what has changed? One thing I have found is that if no date is asked for then the chance of it getting done is usually extremely low...close to ZERO. It seems most people aren't very organized and their job stretches them too thin. They get done what they think is most important. When someone reminds them of a date that is coming up or has just passed and and a task they promised to have done they typically up the priority of the given task. Why is this mindlessness needed?

For one thing we don't trust one another. My wife asks me to feed the kids. 15 minutes later she asks "Have you fed the kids?" This is with someone who trusts you. Take this to the office and know one trusts anyone. Everyone knows all of us are playing games of trying to look good to those that matter so we can get that promotion, that raise, that name it. The game isn't about how do WE win, but how do I win. This type of culture makes getting things done very difficult. You wind up having one meeting to get them to agree to a task and a date. Another meeting to get status (sometimes this even occurs weekly) then a final meeting to go over what they did. It isn't rare that in a given week I spend more time in meetings than getting any work done. The project I am currently on, we have more people in an oversight role that in a doer role. I wonder if we could calculate a performer to oversight ratio for projects. Then map that to might be interesting.

One thing Agile projects try to do is limit no-win situations of date promising. The date is either the end of this sprint or it isn't. The focus then becomes what can the team deliver this sprint. We don't have a number of meetings with various stakeholders, each with their priorities and action items and dates. We have ONE backlog and ONE team. The team works the backlog and NOTHING ELSE. A stakeholder wants goes on the backlog and gets prioritized along with ALL the other requests. None of this back room dealing junk where Bob gets his stuff this week, because we didn't promise Tim his stuff till next week and poor Jim didn't ask for a date so he can just wait. Besides Bob is always calling me and I want him off my back.

With Agile, we put all the cards on the table with all the stakeholders. Let the customer decide what the relevant priority is between Bob, Tim and Jim. Let the developers do the work and stop playing politics. Agile practices allow progress to be made because the rules are simple and well communicated. Anyone who wants work is told the same story. It isn't different because of who the asker is or the relationship to the answerer. It is always: Come to the planning meeting and we'll see where the work lands. The development team is only responsible for delivering what the owners have prioritized. When the simple rules are followed it works well. When the rules are tinkered with to soft peddle the approach. It works less and less well. In some cases it works worse that before. All I want to know is when will you be done?