“Let us speak of Bottlenecks and Silos”, said the Carpenter to the Walrus.

This week I've witnessed an example of the impact of silo management on project delivery and a lack of understanding of what the real problem is.  The company concerned has a strong silo management mentality: they don't just have silos they have silos within silos. They have the silo equivalent of those nested Russian dolls!

A spate of projects has found themselves competing for time and resources in the QA testing department. So the Pavlovian response is that the QA management team needs to have additional support from the PM team to help them manage the issue. Poor throughput and resource contention must be a department management failing, right?

So I was drafted into a meeting to discuss how we could "help" QA to fix “their” problem. When I started to explain that you couldn't analyze a sub-process in isolation and that you had to analyze the entire system you could see eyes starting to glaze over.

One of the failings of software managers is a reluctance to accept pertinent lessons from other industries. The dominant mindset is that software is different from other productive activities and therefore can learn little or nothing from their experiences. So as I related my experiences of manufacturing and Goldratt's theory of constraints, particularly how to identify and manage bottlenecks, it was as if I'd started speaking a foreign language. They sort of accepted my analysis but there was definitely an air of "don't ring us, we'll ring you" in their attitude at the end of the meeting.

What was not accepted, initially anyway, was that the problem was systemic. QA's problems where caused by uncertainty of output from development, allied to changes in management priorities. QA was not the problem, the bottleneck in development was. The fact that QA either had too much to work on or not enough indicated that most of its problems came from upstream, from development. But the strong silo management meant that they could do little to address this issue. Oh, they complained and they communicated but they were powerless.

Because development had its own problems, caused in no small part by a workload that was being created by four different organizations who launch projects without any regard to the plans of other departments. The result is a huge project backlog, with one department, for example, spending the part of every Monday re-prioritizing their 70 plus projects. They have the equivalent of Dick Clarke on American Bandstand announcing the weekly pop music charts, as PM see if their projects have moved up or down the chart. Great joy is experienced when your project goes up. Mind you moving from 41 to 37 is hardly earth shattering. But every organization needs its rituals and circuses.

The result is that the development group has constant pressure to do more projects while being whipped about by ever changing priorities. They can't predict their work which means they can't help QA plan theirs. We have a systemic problem that no amount of fiddling with sub-processes will fix.

I'm awaiting the leadership response.  Which I suspect will be of the "you need to work smarter rather than harder" variety all the while studiously ignoring the fact that is they who need to get smarter.

This is an example of how many people throughout a system know that it is flawed but the strength of the structure prevents the rational discussion on how to fix it. The Silos win and the bottleneck is preserved to wreak havoc for months to come.