edited 4/25/2017 - This is Chapter 1 of a series of Process Improvement articles.
My father Jack Beery led a multinational in Sao Paulo Brazil years ago. He started his career as a business process trouble shooter for Arthur Andersen. I learned a thing or two from him. In many ways my work in business R&D is also process trouble shooting. This article will be told from his perspective and will describe the goings on within a fictitious multinational corporation that launched a new Medical Devices division a few years ago. While I don’t know what company you work for, you should assume any similarity to your own company is purely intentional.
Here’s the situation – Jack has joined our multinational from a recently acquired smaller company where he led product development for the better part of a decade. In his new role, he is a subject matter expert/consultant for the larger Medical Devices division.
The Problem:
Agile Methodology has been introduced; but it’s not yielding the results that it should. Jack is confused, his teams used a light weight version of Agile prior to the acquisition with great success. Yet in the new company, the size of the development team has tripled. The new Product lead tells him that there is a five-quarter backlog in the development queue. Any new projects will be prioritized in the queue at the two day quarterly planning meeting in Boulder Colorado. This likely means that the stuff currently in quarter five won’t be done in that quarter (or any). (Does this sound familiar?)
Analysis:
On the surface, it appears that the processes in place are anything BUTAgile - despite following the Methodology to the letter. So, what happened?
Jack takes a deeper dive into day-to-day operations of the Medical Devices business unit. He shadows a couple of the teams and starts to notice a pattern. Meetings. Meetings scheduled. Meetings missed. Meetings delayed. Management angst over missed meetings. Management angst over long dev cycles. Management angst over integration issues, general angst at the associate level over staffing levels vs work load.
(Naturally) Jack schedules a meeting with one of the local team managers who worked for Jack in the old company. Matt is a director who leads a team with nine direct and indirect reports who together with him have a total of 400 hours available to perform their duties within any week. He has been tremendously successful in his new role; but seems to be running at a pace that is unsustainable. Jack has reviewed his scheduling calendar prior to the meeting and notes that Matt has booked 200 hours worth of staff time with meetings. Discussing his operations, he discovers that Matt thinks that his teams spend about 15-20% of their time in meetings.
This 20% number is important. It establishes Matt's expectation with regard to the cost required to achieve the benefits of these meetings. Yet the reality is that 50% of their time is spent in meetings. Any efficiencies gained with knowledge transfer that occurs at the meetings has been lost to other meetings!
This same pattern exists across the product development operation. A deceptively inordinate amount of time is lost to meetings. The inherent flexibility of Agile and the inherent efficiencies of Agile are the first victims to Chronic Meeting Disorder (CMD).
This is why the team could grow by 3x yet get less done than Jack’s old team.
The Fix:
Jack convinces the executive management team that they can boost productivity by 50% if they institute a policy that limits the total duration of meetings to no more than 20% of an associate’s time (on average). This is accomplished by limiting both the number of meetings and the number of participants in those meetings.
The plan works like a charm, and the backlog shrinks to a more sustainable two quarters.
Summary:
- Problems with Agile often aren't problems with Agile at all. Agile is a tool, it is neither good nor bad.
- In this instance, it was the communication strategy used within the company which had negative down stream effects.
Needless to say, in a perfect world Jack would be promoted to SVP. But that’s another article.
Speaking about other articles, there are quite a number of ways that Agile processes can head south. Stay tuned for further chapters where Jack explores what can go wrong and how to fix it. Chapter 2 will discuss how to make sure your Agile processes are working on the right problems. Hint - If Product is making the business decisions regarding which items are worked on first; or you are using some arcane formula to calculate priorities, you're probably in trouble. Be sure to follow me here on LinkedIn
Disclaimers:
- These Process Trouble shooting articles are not based upon ANY real world companies. The ARE based upon my real life experiences. I've tried to incorporate situations that parallel what I've seen in the world.
- Most of the people in this article are fictional (my dad really existed and he was named Jack).
- In my opinion as the author, I believe employees have an almost sacred duty to work to improve their corporate homes. This means saying what needs saying and not ignoring problems. Everyone has it within themselves to find their voice and fix problems whilst respecting their employers and colleagues .
Originally published on LinkedIn.
