This is one of many entries in the Change Diary: a true story of success and failure, written as it happened.
26 Feb, 2002
Today was a surprisingly boring day. It shouldn't have been--we had a major issue crop up, and today was the last day we could do a drop before releasing to production. But everything proceeded calmly. I don't think I can take all of the credit... but maybe I deserve it. The same scenario in the past has been a nightmare. All of the initiatives I've pushed for played a role in our success:
When I arrived today, a number of issues were sketched out on the whiteboard. I talked to the PM, wrote the issues down on tasks cards, got him to prioritize, and estimated with the help of the other on-site developer. There was a major issue, so I paired with another developer that we occasionally work with, and we worked through the day.
At three o'clock, I overheard the PM say something about doing a drop. This was the first I'd heard of it. When he got off the phone, I asked him whether we were doing a drop today. When he said yes, I told him that I wanted to get home at a reasonable hour tonight, which meant that we needed to start the drop by 5:00. Did the new issue on the board (previously prioritized as "least important") need to go in?
He answered yes, so I told him that since I had estimated it at two hours, I would have to stop working on the major issue that I had been working on all day. Fortunately, my pairing partner was completely up to date on all the issues and could continue working on it without me.
Because we had calibrated our estimates by that point, the PM knew my logic was sound. He didn't argue. I started working on the last-minute task, but did so with a relaxed feeling, confident that I had enough time. My pairing partner continued working on the major issue alone.
I finished the last-minute task around 5:00. I confirmed with everybody that I was going to do a build, and then printed out the build checklist I had put on Wiki. The PM had updated it earlier to correct a problem with the previous night's build.
The build went smoothly and I left right on time!
Looking back at what I've written, it reads like one of those oh-so-annoying made-up examples of a new process in action. But it's all true. I know there's going to be lots of problems ahead, but I think we may have turned the corner. As I said in my introduction, everything I've put into place was used today:
- Central planning whiteboard
- Task-based planning
- Task-based estimating
- Colocated team
- Reliable estimates, leading to respect for developer estimates
- And even a smidgen of active process improvement, in the form of updating a checklist on the Wiki
There's lots more to do, but I think I may have found the minimum process necessary to stem the chaos.
7 Apr, 2006
Success! Woohoo! This was one of the good days. If you're a "peon" attempting an organizational change, treasure days like this. They're all too rare.
It's funny how much a few simple things can turn a project around. Good planning and a colocated team: I've seen it work wonders time and again. Last year, I worked with a team that was struggling to keep up with daily maintenance requests. After we implemented daily planning, team morale was up, productivity was up, and the team was actually finding that it had time to do other development, too.
Of course, by "good planning" I mean something very specific: developers estimating their own tasks and business folks prioritizing those tasks. I also expect that the tasks will be pretty small--less than a day of work. Combine this with a colocated team and a centralized planning whiteboard and you get a pretty powerful result.
I can't promise that this will work for you--maybe there's some magic ingredient I provide without knowing it--but this basic formula has worked for me over and over again. It's the place I would start if I were struggling with a project that has degenerated into chaos.
Next: Week Ten