This is one of many entries in the Change Diary: a true story of success and failure, written as it happened.

25 Feb, 2002

Every day, I make a tiny bit of progress, but I'm also reminded of how far I have to go. It gets depressing. If I were offered a coaching job, I'd take it in a heartbeat. On the other hand, I'm not actively looking for other opportunities. That either says that the situation is hopeful, or that I'm lazy. (Or stupid. My efforts could well get me fired.)

What gets depressing is not that the organization is backwards. That's pretty common. What's depressing is that I have so little control. I know that, given the authority, I could turn this project around. In six months, I could have the whole organization dancing to a happy and productive little two-week beat. I just don't have the authority.

There were a few things that have been working in my favor. The last two weeks have been a debacle for my project. Quality problems up the yin-yang. People working until dawn over a major holiday. Stuff like that.

It's too bad for the project, but it's good for me, and it's good for the project's long-term health. This was bound to happen with the way things were being run. I'm glad it happened sooner rather than later. People are a little more willing to change, and I can make my suggestions with a little more authority. When I made suggestions today, there was more understanding and no disagreement. I didn't try to implement any radical changes, but all the suggestions I made were implemented.

Starting tomorrow:

• The project manager and the QA lead will be sitting in our bullpen
• On-site programmers (all both of us) will be estimating tasks

Yay!

This actually gets us pretty close to where I want us to be. I want:

• Collective task ownership
• XP-style iteration planning
• Fixed-length iterations
• Process introspection and improvement
• Various code quality things, like test-driven design [now known as test-driven development] and merciless refactoring
• Customer communication improvement

We're really close to getting collective task ownership. The idea of iteration planning is well planted, but not quite germinated yet. Fixed-length iterations will take a while. I think iteration planning needs to be well-established first. Active process and code improvement won't happen until the project gets out of fire-fighting mode. Customer communication is a big barrier with its own set of problems. I don't think I can do anything about that until we have our own house in order.

Some agile ideas are in place, but they're very fragile. I've gotten them to sprout, but if I were to leave, they would wither away:

• Central, visible planning whiteboard
• Task-based prioritization with index cards
• Task-based, small-grained estimation
• Colocated team, including "customers:" PM and QA lead

Tomorrow will be an interesting day. I made some big strides today, relatively speaking, but they were in the aftershock of a really hellish week. Will the changes stick? They might, but it's far from certain.

Years Later...

31 Mar, 2006

My attitude seems a little callous, doesn't it?

The last two weeks have been a debacle for my project. Quality problems up the yin-yang. People working until dawn over a major holiday. Stuff like that.

It's too bad for the project, but it's good for me, and it's good for the project's long-term health.

It may seem callous, but I think it was justified. One thing that may not be clear from these diary entries was that the company had a systemic problem. The culture of bullying, reactive firefighting, and death marches wasn't limited to just this project. It led to severe project overruns and problems across the organization.

Besides, it's true. This was the best time for me to introduce some "new" ideas. It's much easier to convince people to try something new when their current approach has just smacked them in the face.

The specific practices I introduced weren't actually that radical. You can see them in the list at the end of the diary entry:

• Central, visible planning whiteboard
• Task-based prioritization with index cards
• Task-based, small-grained estimation
• Colocated team, including "customers:" PM and QA lead

Basically, prioritization and sitting together. Not exactly rocket science for a project that's in bug-fix mode.

As I look at what I just wrote, I'm struck by how small these changes are. I remember them being incredibly difficult to accomplish. Why was that? I honestly don't know. It seems pretty obvious to me that doing these things would help the group get done faster.

In fact, I think it was clear to a lot of people that doing things differently would help improve the situation. I remember hearing people, from the director of the division on down, talking about how bad things were and how much a change was needed. And yet they held on to their destructive practices with every finger and toe.

As I write this, I think I'm beginning to understand what was going on. The organization was under enormous stress. The culture of bullying extended to punishing messengers. The mantra was, "failure is not an option"... so failure was swept under the rug. Little failures, unaddressed by unaware management, cascaded into big failures that were "addressed" by blaming and bullying. This led to a vicious cycle in which fewer little failures were reported, more big projects went under, more blame and bullying, and still more people stopped reporting problems.

Combine this with an "I won't be able to feed my family" job market and you have a recipe for silent terror. (Remember, this was in the middle of the dot-com bust. I knew several out of work programmers. One of them was working as a bartender.) Not a situation in which people are willing to try new things. No wonder I had such a hard time accomplishing so little.

At any rate, I had to take victories where I could find them. These changes may have been small, but they were the result of two months of hard work and cautious attempts at change. This day was a milestone: it marked my first real organizational change.

Burn, Baby, Burn

Despite the "success," you can see me start to burn out in this entry. I had been working with the company for two months at this point. Two months isn't a terribly long time, but that was two months of reactive code-and-fix deathmarch. It had been... um... four years since I had been on a project like that. I had led several complete projects, from start to finish, since then. Each one of them had shipped quality work mostly on time. (One of them--my first XP project--shipped every three weeks, like clockwork, exactly on time.)

In other words, I had a lot of experience with successful projects. I knew how to lead a project and I could see this one being led into the ground. The dramatic error of management--committing to specific dates and functionality without creating a plan based on developer estimates--was taken out on programmers. As one of the peons bearing the brunt of this dishonesty, I was more than a little frustrated.

For the Skeptics

One question you may be asking yourself as you read: "How could Jim be so sure that an agile approach would solve their problems?"

In six months, I could have the whole organization dancing to a happy and productive little two-week beat.

It's an astute question. Keep reading.

Next: Week Nine: Tuesday