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

I started this diary on February 20th, so the following is from memory.

[To clarify, the following entries were written in 2002, about eight weeks after I started the project. Later entries were written on the day in question.]

Week One: Tuesday

1 Jan, 2002

I get hired. I talk with the person I'm replacing for half a day, and then he leaves. Today was his last day. I have a desk and a computer. Time to get to work.

Week One: Friday

4 Jan, 2002

One of the other people here who's into XP is working on an automated build script. There's hope.

Week Two: Monday

7 Jan, 2002

It doesn't take me long to identify the communication problems. I don't feel like I understand what I'm working on or how it relates to anything else. I address the immediate problem by picking up my computer and moving into the bullpen with the other programmers on my project. Fortunately, I'm only assigned to one project right now. With the benefit of hindsight, I can say that this was a great move. I've picked up a lot of information about the project just by being in place to overhear conversations.

Week Four: Monday

21 Jan, 2002

The project I'm on is in its final stages. We're trying to fix defects so we can release to production. We have an hour-long meeting to discuss defects every day. I try to resolve the problem by writing my defects on cards and taping them to a whiteboard. I say, "If you want to know my status, just look at the whiteboard. Everything I'm working on is on there." I estimate costs for my defects as well.

Week Four: Thursday

24 Jan, 2002

No one else is writing their tasks on cards. I stop estimating.

Week Five: Monday

28 Jan, 2002

I keep talking about process improvement and agile methodologies. I'm trying not to be a chronic complainer but I fear that I slip into that role occasionally. On the other hand, whenever I do complain about something, it's in the context of how we could fix it. Still, I think I'm probably being at least a little obnoxious. It's hard to curb my tendencies, though. Maybe writing this diary will allow me to get it out without irritating my coworkers.

On the other hand, my comments are being noticed. Or maybe it's because I was able to start fixing defects within the first week. Either way, I'm being invited to more architectural-level meetings.

Week Five: Thursday

31 Jan, 2002

I take down my cards. The cards got noticed by other people, in a sort of "What's that odd collection of cards on the white board" sense, but they weren't really used by the project manager. The other two people on the team weren't following my example, so there wasn't really a point. I keep using the cards, but I just keep them on my desk.

Week Six: Tuesday

5 Feb, 2002

This organization, like many out-source organizations I know of, wants to increase reuse by building a framework. I had a discussion about process with the architect of the framework yesterday and we had a meeting about it today. My points were well received, and when I suggested that we make them official policy, I got permission. So as to not lose momentum, I wrote up a one-page "official framework policy" document! We now have an agile process for framework development.

The process is very, very simple. It goes like this: Anybody can work with the framework, but:

• you have to work in pairs
• you have to develop test-first.

Before my input, we were going to have a hierarchy of people who were trusted to permitted to modify the framework and people who were not. I convinced them that making it difficult to modify the framework would result in a stovepipe system. That opened the door for an agile approach, and the all-important introduction of required pair programming and test-driven development.

The not-so-good part is that the "official policy" is not so official, as yet. I got permission that this be the official policy, but then I drafted it and sent it out. Nobody has officially anointed it as official. So to speak.

Week Seven: Monday

11 Feb, 2002

I sent an email to the director a few weeks ago saying that I have experience with process improvement and describing some risks I saw with specialization. Today we had a meeting. It was a great meeting in that we got along well and discussed a huge variety of topics. I think I established my credibility. It was not such a great meeting in that there was no call to action. There's an interest in change, but in cautious change. I can't really blame him. I left feeling that I had implicit permission to make minor changes. That's not what he said, but now I feel like I'll be given some slack if I do. I don't have any real authority, but I've always been good at talking people into trying new techniques.

Week Seven: Wednesday

13 Feb, 2002

The task-tracking whiteboard has spontaneously come back to life! No index cards, just markers. That's okay. The cool thing was that I didn't do anything.

Week Seven: Friday

15 Feb, 2002

I've converted the whiteboard from markers to index cards. Not much resistance... erasing and moving around marked notes was getting messy. (As of today, 19 Feb, the board looks great.)

Week Eight: Monday

18 Feb, 2002

The other XP guy has installed a Wiki. It's being adopted enthusiastically by several people. It looks like it will fly.

Week Eight: Tuesday

19 Feb, 2002

I've introduced the idea of prioritization on the tracking whiteboard. I keep asking the project manager to order my cards by priority... and I think it's starting to catch on. I've also gotten the QA guy to submit tasks through the project manager for prioritization rather than just emailing me all the time.

This brings us to the present. Future diary entries should be a little more detailed, and will talk about the problems I face in more depth. The brief entries up to now have made things look straightforward and easy, I think.

Years Later...

17 Mar, 2006

Ah, those status meetings. How I remember them. What a waste of time. I'm re-reading this diary for the first time in years and I can't believe how even-handed I was. Now, thinking back to those "status meetings" really makes my blood boil.

Their Problem

Let me set the stage. I had come in at the tail end of a project that was in its testing stage. (Remember, this company did waterfall development: requirements, then design, then programming, then testing.) The team's tester was finding defects and we were fixing them. There was all kinds of pressure to get done quickly.

Plans were created months in advance as part of the contract negotiation process. Each project was assigned a project manager whose job was to find ways to make reality match the schedule. Clearly a thankless job, since reality objects to being changed. Schedules can be changed to match reality; that's easy. Changing reality, on the other hand, takes special powers.

It's not surprising, therefore, that projects tended to be behind schedule. Take a plan that's created according to a generic formula, estimate the work in advance of any significant knowledge of requirements, have the estimates done by people who won't be doing the work, never update the plan after work is started, and what do you get? Lousy plans... and they were treated as unquestionable truths.

To accomodate this... um... rank amateurism, the company applied a peculiar form of management. It's depressingly popular. Let's call it the "flogging" school of management. The theory is that the more pressure you apply to programmers, the more you make them feel that they're behind schedule, the more you pressure them to work long hours and extra days, the more they'll get done.

Okay, let me call bullshit on this one right now. This approach to management is inhumane. What makes it really inexcusable is that it doesn't work. Go read my Crunch Mode essay for the reason, or Tom DeMarco's Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency for the long version.

So, what does this have to do with status meetings? Everything. Every single day, the project manager would get us all in a room for an hour. Then, one programmer at a time, he would go down that programmer's list of outstanding bugs and provide us with "commitment dates" for completion. I have no idea how he came up with those dates. If something wasn't done by its date, he would push. "Working late tonight?" "Can you work over the weekend?" "We really need these to be in the next drop." The whole point of the meeting was to apply pressure.

Let's think about this. Long days. One-hour status meetings every day. (That's 10% of our time right there!) Aggressive, pushy "management." Result? Burned-out, unmotivated programmers who were being shown, every day, that wasting time was okay. Why did anybody think this would work?

My Problem

My approach was to try to make the project more efficient. I saw that we could get an extra hour out of each day by eliminating the daily status meetings. Meetings are a terribly wasteful way to disseminate information. A simple status board that's updated when status changes is much more effective. I tried to create such a status board by writing my bugs on cards and pasting them up where anybody could see them. When I finished a card, I circled it with a green marker.

Looking back, the cards were a good solution. I'd do the same thing today. I made two mistakes, though. The first was with the project manager. The second was with the team. The second was particularly bad: it affected everything I did at that company.

The small one first. Back then, I thought the project manager was conducting daily status meetings to gather information. Using cards would have helped him have more accurate information more quickly: a good thing! Except that's not what he was after. I realize now that he conducted status meetings because his job depended on the project coming in on time. Applying pressure was the only tool in the toolbox. From his point of view, a passive status mechanism was a terrible idea: there's no flogging.

I made a much bigger mistake in the way which I introduced the cards to the rest of the team. I didn't involve the rest of the group in the decision. I just started doing it and talking about how it would make things easier.

I haven't actually re-read the rest of my diary in detail yet, but I seem to remember making this fundamental mistake over and over. It was really a problem of arrogance: I thought I knew the answers and I thought all I had to do was show the yokels how to do things right.

No, I didn't really think of people as "yokels." I knew this arrogance was a problem and I tried to suppress it. I even wrote some notes about not being arrogant. But arrogance simmered deep-down. It prevented me from going to the group and asking their permission to make decisions together. Rather than work with the group to come up with good ideas, I tried to sell the group on my ideas. If I had worked with them, I would have been much more effective.

Maybe I'm judging myself too harshly. My reasons may have had less to do with arrogance and more to do with wanting to use what I knew. I had had a string of successes, all of which used the same basic XP playbook. Part of that playbook was the card-based status board I was pushing. I was trying to introduce XP because I knew it worked well. These days, I still prefer XP, but I have the perspective to make changes to my playbook and go in new directions.

If I had it to do over (and thank goodness I don't), I would have talked with the group about status meetings, proposed cards as a solution, asked for their ideas, and then gotten their permission to start doing something. Then, if they agreed, we would jointly take it to the project manager. He still wouldn't have liked it... but he would have gone along with it. Flogging isn't a technique you admit to.

Next: Week Eight: Wednesday