Meeting Madness? Don’t Do it!

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.

Worldwide project management conference call to drive software defect repair 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 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.”

Software defects remaining to be fixed - trend does not change when the meetings are started 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.

Thank you for bookmarking and sharing these articles as this tells me which ones are the most helpful.

Filed Under Communication, Reporting | 8 Comments

Tagged With Communication, Defects, Meetings, Project Management Tools, Reporting, Software, Tracking

Comments

8 Responses to “Meeting Madness? Don’t Do it!”

Meeting Madness « Bruce Benson on July 23rd, 2009 8:49 am
[...] [...]
Aurora Palesca on July 28th, 2009 1:15 pm
I like this! I used to manage an online graphics production studio. I held weekly meetings with my studio members, but never found that they were at all useful in surging productivity. However, I found great results when I used the meetings as an open forum for sharing ideas and advice within the studio. The theory is simple: happy, motivated employees produce higher quality products at higher rates!
Also useful were daily “stand up” meetings. For these, the management teams would meet every morning to discuss any pitfalls or holdups in the process. We spent 15 minutes maximum. I have to say that walking away from these meetings always helped me to focus my daily energy where it was needed most.
Bruce on July 28th, 2009 8:01 pm
Aurora,
Good point. I emphasized in my example that the meeting didn’t accomplish the intended purpose. However, many folks found the meetings useful for other reasons – just not for the stated purpose of driving down the defects.
Were the daily “stand up” meetings truly stand-up? I’ve found they often work best when everyone gathers, talks, then splits up. No settling into chairs and getting comfortable.
Thanks for the thoughts.
Bruce
Mark on August 3rd, 2009 12:12 pm
Bruce;
Spot on article. Definitely brings back memories (some even good!). I’ve been looking at Agile Methods and am convinced there is some good potential. For example take a look at the daily scrum meetings and I think you’ll find it tries to provide a framework that builds on some of the better aspects of the information exchange while leaving some of the artificial “this is how we drive the team” methodology out. It will be interesting to see if there is real world feedback on how the agile and traditional pm methods get integrated over time.
-mgk
Bruce on August 3rd, 2009 4:51 pm
Mark,
What I liked about Scrum (Agile management method) was the “burn down” metric. It is central to Scrum management. As you know, metrics are all too often “tweaked” and start to lose their usefulness as a management tool. My fear is in organization that likes to “fix” measurements that in their hands Scrum and other Agile techniques will suffer the same fate.
Our old common company is trying to use Scrum. This should be a perfect laboratory to see how the two worlds collide. So far, based upon quarterly financial releases, I don’t yet see much change.
Thanks
Bruce
Kendra on August 19th, 2009 8:11 am
Do you really feel that daily meetings are helpful? We are a small team of 2 developers, 2 designers, and 2 PMs. I feel these daily meetings are not effective for us because we are all working on different projects; if we run into issues, we are a small enough team that we talk about those issues in the moment.
Bruce Benson on August 19th, 2009 9:29 am
Kendra,
Every situation, of course, must be assessed on its own merits and needs.
Only interacting when a specific issue comes up has some limitations. I’ve seen cases where everyone thinks things are going fine, until they get together and talk about what they are doing. Then they realize someone is going down the wrong path or someone is duplicating what another is doing, etc.. So periodically getting together as a team is necessary.
Quick stand-up meetings where everyone gathers — stands — and the meeting only runs 10-15 minutes can be useful for keeping teams focused on common goals (and for team identity and building).
Generally, I find many meetings are just “fixes” for other things are are not going well: goals constantly changing, schedule constantly changing, scope constantly changing, no other way of getting information is available, etc.. So when suddenly more meetings are needed, there is often an underlying cause that needs to be fixed. Once that is done, the need for so many meetings can go away.
Bruce
Leonard on July 3rd, 2010 4:44 pm
While I’m getting my second helping of popcorn, so, how long did the madness continued? I see a linear trend, so I get the point, more meetings, less meetings, weekend meetings, the defects/bugs where fixed at a constant rate. I predict about 10 weeks later the last 200 defects were fixed. Still wondering.. did they see the light?

Leave a Reply

Project Management Tools | Meeting Madness? Don’t Do it!