All I had to do was to get about 500 software defects fixed, according to my project management tools. My boss told me I had to have daily meetings with everyone concerned to get this done. This meeting centric approach to managing this project turned out to be utter madness. Simple measurements, that anyone can do, demonstrated that these meetings had no discernible impact.
Five hundred defects. That was my job. To get all those defects fixed and put into the product. Once that was done, the product was done. I was to “drive” the development teams to get them fixed.
Great. I can do this. Pretty easy. Talk to the dozen development managers. Get a plan for when they will have their defects fixed. Monitor their progress against the plan and report weekly. Piece of cake.
We do this for a couple of weeks. I have a nice chart showing the defects are coming down. Slowly, but they are coming down.
I have to explain to my management about defect arrival rates. We still have defects coming in. Testing is still finding issues. The 500 count was just a snapshot in time. There are new ones coming in even as we fix the existing ones. You would think my management would understand this. Instead my management gets visibly upset when I show how many new defects have arrived. They want the backlog of defects to come down faster.
“Why are you not having daily status meetings?” My boss wants me to call a meeting with all the development managers every day. He wants a daily status on each and every defect. He says this is how we “drive” the development team. Hold their feet to the fire. Ask them each day on every defect what their progress is. What is blocking them from fixing the problem? Get them to tell us their status every day.
OK. I can do this. Every morning at 8 am, I now have a worldwide conference call with the dozen development managers. Actually, there are upwards to a hundred people on the call. Individual developers are on the call. Their development bosses have asked them to join the call so they can answer my detailed questions about each defect. The development manager’s bosses are on the call. They want to know why I am having all their folks on this daily conference call. The test team is on the call. They want to explain why this or that defect is really a defect and not a testing error like the programmer keeps telling them. The account teams are on the call. They want to know if we have prioritized their customer’s defects high enough that they get fixed first. Chaos ensues. I take control.
I rule with an iron discipline. The call starts exactly at 8 am. I start calling out development managers and list off their defects one at a time. I expect to hear if the issue is resolved. If not, has it been reproduced yet? If not, what are they doing to reproduce it? If the defect has been reproduced, do they understand the root cause yet? If so, do they have a solution coded yet? On it goes. It is a nice little process. We go through the list about one defect a minute. It is a detailed but painful process. I keep meticulous notes in a database. We get a lot of good data. I love data.
My boss is on the conference call. He likes it. He even often takes over the meeting and asks the questions. It is not as fast that way, but he is happy. The senior managers are happy. We are driving the development team. They will really make progress now. We are helping development to solve all these defects.
I’m not sure I agree. You see I love data. Did I mention I was tracking and charting the rate at which defects arrive and the rate at which they are fixed (see Defects Are Your Best Friend – Project Management Tools)? I’ve been following our progress since we started. I have the trend before we started the daily meetings. I have the trend during the time of the daily meetings. It looks the same. The daily meetings have made no obvious difference. That surprises me. There are so many people on the conference call. We are often on the call for hours at a time. I am surprised that it did not slow down the rate at which we fix things. It certainly did not speed it up. Yet, my bosses see me as “doing my job.”
I show my bosses my trend charts. The development team is working down the issues at about the same rate they had been working before the daily meetings. The charts make everyone uncomfortable. They can’t be right, they say. We are driving the development teams! The charts are seemingly ignored. Or are they? In fact, my bosses now want twice daily meetings. One in the morning and one in the afternoon. We are going to fix this backlog of defects. Really get things going.
Later on we would also have weekend status meetings and at one point, even status meetings three times a day. My trend charts showed no significant change in the trend of fixing defects. None. It showed the same regular progress we had seen before all the meetings started.
The daily, twice daily and weekend status meeting, as a way to move the product development along, was a staple of this organization. In almost 10 years of tracking product development, not once did I ever detect a change in how fast things moved along due to the starting or stopping of these meetings. Not once. We had hundreds of staff hours sitting on each conference call and before those calls, collecting up status information. I was always amazed that I never saw a reduction in progress. I came to realize that the development organization had a cadre of folks whose primary purpose was to “feed” these daily status calls. These meetings made no measurable difference, but they were considered an essential part of the process.
Many things can be measured, even the impact of calling meetings. You can use project management tools as sophisticated as Six Sigma, but even simple measurements will often show you what impact, if any, you are really having. With some simple measurements – you too can avoid meeting madness.