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.
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.
24 thoughts on “Meeting Madness? Don’t Do it!”
Comments are closed.
Hi Bruce,
Indeed, patience is one key. The other key is a Neanderthal with an inquisitive mind. If new ideas scare/challenge the Neanderthal, even leaving the BIC lighter laying around the mouth of the cave will just drive him deeper into the cave, with his back turned, rubbing two sticks together trying to start his fire, mumbling about “idiots, don’t they know that short burning stick will burn their hand”.
I have done as you suggest regarding charting the trends, tho interestingly enough, it was to show that dropping an offshore development team to save $$$ would cause the the defect backlog to rise to the thousands over next 6 months. It was a successful education, Management saw the numbers, and extended the offshore team for 9 months.
There seems to be some perception that the # of incoming defects will slow down, even if nothing proactive is done about the arrival rate (Einstein’s definition of insanity applies here). I think it’s perhaps related to the person’s background, and think it might be a Services background that brings this idea – where Services mantra is “get in, do it, get out” with no worry about future – that’s Support and Maintenance teams problem. Services just has to fix N defects by go-live, and usually customer testing is limited at best. But perhaps there are other reasons.
Side note on Neanderthal – this isn’t to suggest stupid – as the neanderthal knew far more about survival in the wild than I’ll ever know. It’s more about the completely foreign environments, from the wild to the modern world. Me going back to the wild would appear far dumber than the Neanderthal does in today’s world. 🙂
ciao,
mm.
Deja vu all over again! I’m getting flashbacks from your description about management focusing on a 500 defect snapshot in time, as if somehow, that is the universe of defects, there are no other defects coming, and once the snapshot=zero, then quality is proven. Whether the focus is thru daily meetings or not, the bottom line here is failure to grasp the formula: open defects plus new defects minus fixed defects equal backlog of defects. What part of “new defects” is so difficult – meeting or not?
Where does this come from? what part of arriving defects doesn’t Management understand? I’ve tried the analogy of a firehose of incoming defects, and asked management who is monitoring the shutoff valve and get only deer-in-headlights looks.
A related concept is given two software modules, with similar size and similar testing, if one module A has had 100 reported defects and all are fixed, and one module B has had 10 reported defects and all are fixed, which module A or B will have most # defects reported by the customer? The guess is usually B, but that is incorrect, as once buggy code fixed a lot remains and sometimes is more buggy than when fixes started to be applied. Management I’ve worked with can never grasp this concept – so they continue to focus on the 500 or the 100 open at time of snapshot, and believe somehow that getting those fixed is the end of the quality problems. Meanwhile, the fire hose of defects continues at full throttle open.
Someone tell me how you explain a BIC lighter to a Neanderthal – and that’s how management will learn about arrival rates. How do you explain to the Neanderthal that the lighter will not burn his hand? That the ligher is much easier to use to start a fire. How, how, how? Solve that problem, and life will be so much better.
Mike,
Actually, it is pretty easy, if one is patient – and doesn’t get replaced before insight is achieved ….
For most people it is a matter of being introduced to the concept and then hearing about it regularly over time (i.e, use the information, show how it predicts how we are doing, manage with it, etc.). Once they have heard about it for awhile, it becomes one more thing that becomes normal and “obvious.” In one case, after getting a development VP indoctrinated with the insight, he did tell me “yes Bruce, I’ve seen the numbers – but we still need to ship by ….” So it is a long term process for some people (we shipped months after the “need” date).
I do often have to use it in a secondary manner to start. Show the normal status, reply in the expected way (e.g., “we’ll be working around the clock to have it all done by Friday!”). Then, show the arrival rate curve and trend as “Also, this is interesting. We’ll need this arrival rate to go down more. Its being fairly consistent and only decreasing by X defects a week ….” When the arrival rate only goes down a bit — not enough to support finishing by Friday (next month, etc.) — offer a “risk analysis” that the arrival trend suggests a low probability of making it by Friday. So it is frequently about offering it up in small doses and growing the use as folks start to get familiar with how defects trend over time.
Springing any new concept or method on someone can often bring out their Neanderthal side.
Good comment.
Bruce
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?
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.
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
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
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
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
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.