“Ninety-five per cent of changes made by management today make no improvement.”
Dr. Edward Deming - “The New Economics” 1994
It is no secret that Deming often chided upper managers as being the cause of bottlenecks, revenue loss, and ill-conceived decisions based on short term thinking that is the result of the lack of utilizing sound data driven processes and decisions. The Agile movement is just as notorious for blaming management as well as the bureaucratic organizational structures which in turn create the need to compartmentalize people and feed the desire to have them all follow a prescribed waterfall-ish process.
So it was serendipitous that I ran into this blog post from a “Lean and Kanban” advocate from Germany named Arne Roock, who states to “stop bashing managers”. As he states:
First of all we should not offend all the people with management titles out there. Furthermore I’ve argued that we need people who are not part of our autonomous teams. They need a good standing in the organization and must have a good understanding of our systems. They are responsible for managing the team’s interactions, re-designing the system and observing and acting upon local optimization. And sometimes they need to change the setup of a team. For me, that’s exactly what a good manager does. So let’s stop bashing managers and start working on establishing another understanding of management!
This pie chart from the post does a good job of mirroring management based organizations in the world:
Interestingly, one could say about 95% of the companies out there are run by a hierarchical management structure. And the ones who claim not to have a management structure is probably because they are small solo or run by a few partners type businesses, that at some point will start hiring management when they grow. So the realities are that it is virtually impossible to work in any company of some comparable size and scale that would not have some type of management in place.
Even ones who are adopting so called “management-less” structures such as Zappos’ agenda to follow a “holarchy” style structure will inevitably have some management structure in place. In fact, one could argue that the CEO Hsieh’s very agenda to have a management-less structure was made because his is in fact the head manager!
The famous father of modern sociology, Max Weber, advocated that capitalism, ironically, could not run without bureaucracies and managers because to do so would run contrary to the egalitarian and democratic foundations of a country like America for as he famously stated:
In order that a manner of life well adapted to the peculiarities of the capitalism… could come to dominate others, it had to originate somewhere, and not in isolated individuals alone, but as a way of life common to the whole groups of man.
In other words, if it were not for bureaucratic management in place both in government and companies, there would be no check points for decisions to be made such that equal voice and equal votes could be vetted for all involved.
What it boils down to is an Agile paradox: What are the necessary evils of management that need to be in place, so that they do not become just evil necessities that hamper our ability to deliver projects with high velocity?
What’s your answer?
P.S. – I wrote a post on my site about project managers being perceived as necessary evils as well. Let me know what you think!
Last year Zappos made big news by announcing that they would get rid of job titles, managers, and the infamous functional hierarchies. For as this article from Quartz outlines:
During the 4-hour meeting, Hsieh talked about how Zappos’ traditional organizational structure is being replaced with Holacracy, a radical “self-governing” operating system where there are no job titles and no managers. The term Holacracy is derived from the Greek word holon, which means a whole that’s part of a greater whole. Instead of a top-down hierarchy, there’s a flatter “holarchy” that distributes power more evenly. The company will be made up of different circles—there will be around 400 circles at Zappos once the rollout is complete in December 2014—and employees can have any number of roles within those circles. This way, there’s no hiding under titles; radical transparency is the goal.
Rather than a traditional hierarchy compartmentalized into functional areas, a holarchy is more of a concentric circle of embedded layers, much like an onion wrapped around an individual with a specialized role. Here’s a good illustration of a city gone holarcy:
With all the talk of Agile and its emphasis with small co-located and self-organizing teams, would this structure be more conducive for it? A company filled with these holarchys would look similar to a “Scrum of Scrums”.
Aside from the announcement by Zappos (which was probably more of a PR stunt), I have not heard more about this onion style corporate structure, so it might all be just a bunch of malarkey!
What do you all think?
I had written previously about Agile 90% problem, in that once you gain a wide adoption of Agile in your organization, it becomes harder and harder to squeeze more productivity gains from it. Kanban which has its roots in manufacturing is now one of the pet processes in Agile, especially as it pertains to Lean software development. Therefore, it was of utmost serendipity that I ran into this video clip from TV Land taken from an infamous “I Love Lucy” episode where Lucy and Ethel faked their way into jobs in a candy factory and the disastrous results that inevitably ensues:
The metaphorical and ironic subtext of this video clip could not be more applicable! For I believe Kanban has a similar though different efficiency problem that Agile in general has, in that as your workflow becomes more efficient in Kanban, the more work your organization will pile on top of you. Sure, you can try to control it through constraining WIPs, but just like Lucy in the candy factory, they will slip through while you and your teams are struggling to juggle them all in a tragic-comical manner.
In the end, it is just as much about effectiveness as it is about efficiency and the moral of the story is “be careful what you wish for as you might just get it and once you do, you better have a backup plan!” More on this topic to come.
This article in Bank Systems & Technology states that Capital One is now using Agile methods for 85% of software development projects. The indications seem to be that it has been quite successful for them, as the article states:
When Capital One started to roll out agile development in 2011, Wolfs said it amounted to just 1% of software that was delivered. Today, 85% of software is delivered by the agile method. With agile, Capital One now also releases approximately 400 products a month, has cut delivery times to three to six months while "cutting costs significantly," and finds 95% of products meet expectations on the first release, according to Wolfs.
This is all good, but one thing these kinds of articles do not talk about is what to do when a newly implemented method or process like Agile becomes routine and the initial gains taper off. I witnessed a similar phenomenon at a prior employer where there was an initially high performance increase and waste reduction after implementing Six Sigma and Lean, but once they started to taper off, it became harder and harder to maintain those gains.
At one point, people were spending more time trying to optimize processes that were already optimized as much as they should be where the gains were hitting the point of diminishing returns. I call this the “90% problem” since once you hit that milestone to where ninety percent or more of a method or process becomes the de facto standard in any organization, the costs to get the remaining 10% outweigh the profit of trying to achieve it. But because people are so close, they spend way more time than is necessary trying to achieve 100% which is impossible.
This is where it becomes more of a liability and when people or organizations start giving up looking for a “new solution”. It’s an ever recurring cycle. My feeling is that Agile itself has hit this productivity wall. Now the question is what is the “next new thing”?
It is dawning on me that in the world of project management (and business management in general), that we are too obsessed with managing complexity and reducing chaos which are becoming more inevitable in our increasingly dynamic and hyper-connected world. The concoction of tools, methods and processes that has flourished in the Agile community in the past two decades has all been in one manner or other, simple variations to address complexity and the ensuing chaos that results from this.
Maybe it is time to go the other direction and embrace complexity and exploit chaos. This is very new and I’m still thinking it through, but rather than the reductive process of extrapolating out the clearly defined project activities in a controlled iteration, could there be a way to let these “run loose” so to speak, see what kind of behavioral patterns and team dynamics result and just help facilitate the team to channel the flow patterns till they deliver what they need?
I know this is what many of the well know Agile methods are supposed to facilitate, but I don’t think they go deep enough or really exploit the small perturbations that could result in big breakthrough productivity gains.
In any event, rather than Agile I would like to call this Fragile project management. Because it’s the kind of project in which you must constantly “handle with care.” More explorations to come!