Thursday, April 26, 2007

The other 95% are management problems

I do like this Mary Poppendieck post from earlier this month. Sorry to take soooo long to blog about it.

I do love the ‘The other 95% are management problems’ statement at the very end.

I’ve seen developers thrashing through multiple assignments many times, and in my experience it is usually caused by one of two things:

1) The organization can’t make up its mind what is important for one reason or another, so it tries to do everything. To me this is fundamentally a management problem – it is a basic management obligation to assure that the organization has the capacity to accomplish what it chooses to do. Releasing all sorts of work that is un-prioritized or with changing priorities is neither fair to workers nor an effective way to accomplish work. Releasing a ton of work and expecting it to flow is equivalent to sending a mass of cars onto a freeway (eg. after a sporting event) and expecting traffic to flow. Anyone who understands traffic jams should be able to understand that trying to do too much work is one of the best known ways to get less work done. There is massive evidence to support this – and managers usually know this at some level, yet often choose to ignore it. Those who do not limit assigned work to the capacity of the organization to deliver are ignoring the evidence and not doing their job.

2) There are large caches of waste sitting around the organization that are either invisible to the development team or that are impossible for them to address. This could be lack of clear definition, poor tools, a process which separates different functions and expects them to work sequentially, a practice of not testing until LOONG after coding so that test-and-fix cycles dominate the development agenda – and on and on. In almost all cases, these are SYSTEM problems, not developer problems.

One thing Deming would be sure to say, were he alive today: The likelihood that the organization’s problems are being caused by workers, or can be solved by workers, is maybe 5%. The other 95% are management problems.

Mary Poppendieck

In a previous post, I comment how Mainframe COBOLs two big problems were the nature of the language & lack of active new tool development over the last 20 plus years.

Of cause, for any organization that has these problems today, it really is a management problem. Said organizations have had lots of years to extract themselves from this situation.

The post is at: Yahoo Groups in leandevelopment

I’ve also extracted the sub-thread into this blog post:

How do you break the cycle?

Posted by: sambayer
Tue Apr 3, 2007 12:37 am (PST)


I'm working with a software services organization that wants to transition their implementation processes to lean. Today they are suffering from a lot of wip, big backlog, and lengthy implementation cycles....>8- 10 months. We're dedicating a team to get through one implementation in 1/3 that time. The problem is that everyone in the organization is multi-tasking. Everyone is handling multiple clients at various stages. To add insult to injury, a few employees just left leaving them even more shorthanded. How do we get them off of their "multi-tasking" wip addiction?

Management is behind our experiment because the potential results are dramatic. The challenge we're facing is figuring out where and how to break the multi-tasking addiction. Any suggestions would be greatly appreciated.


Tue Apr 3, 2007 11:53 pm

Hi sambayer, you wrote:

> I'm working with a software services organization that wants
> to transition their implementation processes to lean. Today
> they are suffering from a lot of wip, big backlog, and
> lengthy implementation cycles....>8-10 months. We're
> dedicating a team to get through one implementation in 1/3
> that time. The problem is that everyone in the organization
> is multi-tasking. Everyone is handling multiple clients at
> various stages. To add insult to injury, a few employees just
> left leaving them even more shorthanded. How do we get them
> off of their "multi-tasking" wip addiction?
>
> Management is behind our experiment because the potential
> results are dramatic. The challenge we're facing is figuring
> out where and how to break the multi-tasking addiction. Any
> suggestions would be greatly appreciated.

You are fortunate that management is backing your experiment.

To break your addiction I recommend that you use the [i-don't-know-what-its-called] principle:

1) Explain to everyone that their job is to improve how they accomplish their responsibilities as part of how the company delivers value to its customers.
2) Help them learn to see the waste in the way they work.
3) Help them learn to improve how they work using the Scientific method.
4) repeat all the previous steps

That's it. The learning part is where you can bring in the advice and insights of others, such as the advice from the other two people who respond to your post, into your unique environment, i.e. you learn and understand principles and apply them to develop your own best practices.

While multi-tasking is bad, see Peter Abilla's excellent analysis based on the physics of systems showing this,
http://www.shmula.com/375/multi-tasking-leads-to-lower-productivity, you and your colleagues need to understand your context and commitments and what the issues are in your environment before you start making changes. You need to ensure that you make improvements not just change. The good news is that you and your colleagues already are Subject Matter Experts (SME) on your environment, so you just need to change how you look at your work and environment. There is a wonderful example of this in Matthew May's book, The Elegant Solution. In Chapter 15 he recounts how instructors from Toyota, worked with LAPD staff and in 1 day came up with significant suggestions for improvements in many different problem areas. The LAPD staff were the SME, the Toyota instructors just help them to see their environment and what were the root causes of some their problems and then they helped the LAPD staff to suggest ways to they could improve their ways of operating.

Regards
Norbert
-----
Norbert Winklareth
Agile Renaissance

Wed Apr 4, 2007 1:22 am

>>>
While multi-tasking is bad, see Peter Abilla's excellent analysis based on the physics of systems showing this, http://www.shmula.com/375/multi-tasking-leads-to-lower-productivity, you and
<<<


Hey, I'm *against* multi-tasking as much as anyone. But if it's so bad for us humans, then why is it *good* for operating systems? I'm at my best when I'm mulling over several problems at once. To make a broad statement that multi-tasking is bad is awfully sweeping. Maybe some types are ok afterall. The main thing that I I try to provide for developers is an uninterrupted *zone* time of 2 hrs, twice a day. During the zone there are no interruptions, no context switching, no nothing!

Mel Bartels

Wed Apr 4, 2007 1:32 am
Management is behind our experiment because the potential results are dramatic. The challenge we're facing is figuring out where and how to break the multi-tasking addiction. Any suggestions would be greatly appreciated. I think there is a fine line between multi-tasking providing a "cross fertilization" of ideas, and inundating you with so much "fertilizer" that you can't see the daylight.

I guess it's all about moderation.

All of our employees complain about being overworked and too much multitasking going on. How do you know if that's really the case, or if they are just complaining?

Sam
Posted by: Mary Poppendieck
Tue Apr 3, 2007 7:12 pm (PST)

Hi Sam,

I've seen developers thrashing through multiple assignments many times, and in my experience it is usually caused by one of two things:

1) The organization can't make up its mind what is important for one reason or another, so it tries to do everything. To me this is fundamentally a management problem - it is a basic management obligation to assure that the organization has the capacity to accomplish what it chooses to do. Releasing all sorts of work that is un-prioritized or with changing priorities is neither fair to workers nor an effective way to accomplish work. Releasing a ton of work and expecting it to flow is equivalent to sending a mass of cars onto a freeway (eg. after a sporting event) and expecting traffic to flow. Anyone who understands traffic jams should be able to understand that trying to do too much work is one of the best known ways to get less work done. There is massive evidence to support this - and managers usually know this at some level, yet often choose to ignore it. Those who do not limit assigned work to the capacity of the organization to deliver are ignoring the evidence and not doing their job.

2) There are large caches of waste sitting around the organization that are either invisible to the development team or that are impossible for them to address. This could be lack of clear definition, poor tools, a process which separates different functions and expects them to work sequentially, a practice of not testing until LOONG after coding so that test-and-fix cycles dominate the development agenda - and on and on. In almost all cases, these are SYSTEM problems, not developer problems.

One thing Deming would be sure to say, were he alive today: The likelihood that the organization' s problems are being caused by workers, or can be solved by workers, is maybe 5%. The other 95% are management problems.

Mary Poppendieck

952-934-7998

www@poppendieck. com

Author of: Lean Software Development & Implementing Lean Software
Development