Glass Case Planners
Last week* I saw Narek Alaverdyan give an inspiring Agile London talk on his work at Hotels.com transforming their delivery cadence, creating the ability to experiment and fail early, and so deliver more value to the business.
This image, from his talk, of factory staff managing the work from the safety of a glass walled office high above the production line resonated with me:
It reminded me of one of my favourite Anti Patterns, from the book of the same name, “The Glass Cased Plan”:
Often, a plan produced at the start of a project is always referenced as if it’s an accurate, current view of the project even if it’s never updated.
Anti Patterns p222.
In Alaverdyan’s picture it is the planners themselves who are in the glass case, away from the work on the factory floor.
As was clear from Alaverdyan’s talk, for the complex, emergent work which characterises software development this does not work.
Don Reinertsen in ‘The Principles of Product Development Flow’, contrasts manufacturing with product development:
In manufacturing it is both feasible and beneficial to make all our economic choices in one large batch before we start the work.
Some product developers aspire to use the same approach in product development. They prepare a minutely detailed plan at the beginning of the project and measure performance against this plan. When they deviate from this plan, they take corrective action. They aspire to front-load their decisions. While this is a superb strategy in repetitive environments like manufacturing, it is a terrible one in product development.
Why? In product development, we continuously receive new information from the market and from the design process. Customer preferences change. Engineering tasks that looked easy at first may now require breaking the laws of physics.
The Principles of Product Development Flow p38.
It was when reading one of Chris Matts’ blog posts that it struck me that what Reinertsen was describing was the difference between complicated work and complex work:
If you know in advance what is needed, you are in a complicated system. You can specify and plan in detail to create an optimal delivery at scale (A long lead time and short duration). Hence the space shuttle. Complicated systems struggle to react to changes in context which can cause analysis paralysis. In product development, complicated systems are managed and dominated by experts. The axioms of this paradigm are untested assumptions. This is the realm of early commitment and the slaying of valuable options. As a cautionary note, these systems have the potential to suffer a catastrophic failure if they choose to ignore the context changes.
This distinction between complicated and complex comes of course from Dave Snowden’s Cynefin framework. Matts’ post is well worth reading in full for an illuminating description of Cynefin.
In order to work in the complex domain you need the people who get the context to be empowered to make decisions.
With no power comes no responsibility
The last time I saw Matts he was wearing a T shirt baring these words. At first I just thought this was a cute quote from the Kick-Ass movie.
Then it struck me, in every software development endeavour I have been part of, the power needed to be outside the glass case of management, in the work. Rather than experts looking down on the work, the decision makers need to be positioned to respond quickly to feedback and empowered to do so.
This is the ‘power’ in empowerment. It is why that word means so much more than the ‘delegation’ which managers such as I are often want to use.
The complex nature of the work means the people doing it know best how to respond to it, shape and direct it.
This is not anarchy. If a team self organises without any context you are just replacing one glass case with another. It’s just that the glass case is around the team.
It does mean that as a manager you need to let go and trust the people doing the work. You act on the system, the context people work in, and together find the most effective way of working.
This is not something I find easy to do. What is easy is for me to bring my expertise to bear on the work. Doing so ignores the work’s emergent nature. It is a voice shouting from the remove of a vantage point too distant from the work to act fast on the feedback that comes from it.
What is needed instead is a way to signal when I should get involved, and the people doing the work to have the power and responsibility to act, pulling me in as needed.
* This was originally published in August 2014
