Rapunzel’s Ivory Tower

Share
Reading time ~4 minutes

“If the problem exists on the shopfloor then it needs to be understood and solved at the shopfloor” – Wikipedia

Some years ago I took on an agile coaching role at a very large corporation. Like many stereotypical large corporations, they were seen as data-driven, process and documentation-heavy. Management culture was perceived as measurement-focused, command & control and low-trust.

They had a very well established set of Lean practices and managers promoted strong values around empowerment. Despite Lean training for all staff, there was still a very limited “Go See” culture.  Above a certain level it was still traditional management-by-numbers and standardization – mostly by apparent necessity through scale.

James Lewis recognized some of these challenges. (but was perhaps more brutal than my insider view)

At the start of the transformation the leaders wanted to know “who’s agile and who isn’t”.

Disturbing as the thought might seem, their motivation was sound. We’d all put our careers on the line to “go agile” in order to turn around a struggling group. The last thing needed was a disaster project with “Agile” being labelled as the cause of failure.

(Nearly 2 years further down the line, we managed to have at least one project fail early and be recognised as saving over a million dollars).

We developed an extensive “agility assessment” in order to teach all those involved that “being agile” wasn’t a binary question and wasn’t just about Scrum practices.

The measurement system for the assessment acknowledged that whilst there may be “good” answers, there are no “right” answers or “best practices” – teams could actually beat the system. (If there were “one true way” of developing software, the industry would be very dull).

Beyond measurement, the big challenge I and my team faced was the pressure to “operationalize” agile. To develop common standards, procedures, work instructions, measurements and tools worldwide. The Quality Management System (QMS) culture from our manufacturing background meant that interpretation of ISO accreditation needs was incredibly stringent and was required in order to do business with many customers.

Ironically that requirement kept us almost entirely away from the teams delivering software!

Operationalization was what our managers were asking for and it was very difficult to say “no”. Traditional corporate culture defined this as the way things should be.

So from stepping into a role where we expected the gloves to come off, where we could get out of the management bubble and start making a real difference with teams; within a few months my entire team found themselves unwittingly captive in an ivory tower.

We saw it coming and felt powerless to stop it but as permanent employees fresh into our very high-profile roles, those painful home-truths could not be comfortably raised.

I and my team spent that first period doing what was asked of us and helping teams out for the odd few days at a time wherever we could.

Fortunately all was not lost. At the same time, we invested in a highly experienced external group to engage on each of our sites and drive some of the changes we needed to achieve from within the teams.

Was the value I’d hoped to add in my role lost? – Actually no.

The managers got what they wanted – heavily seeded with a our own more balanced agile/lean understanding and experience.

We weren’t perfect but made a significant series of improvements. The teams actually delivering products had far more experienced consultants supporting them, who as contractors could take the right risks that permanent staff could not have done at the time.

This 2-tier approach actually gave the delivery teams more air-cover to find their own way whilst we worked on coaching the management.

The teams still had a long way to go but were heading in the right direction and getting progressively better. At the same time, the management team learned that Agile isn’t simply a case of running 2 days Scrum Master training, developing a set of procedural documentation and expecting that everything will show 1,000% improvement.

After the initial bedding in period, I and my team were able to build up sufficient trust with our leaders that we could set future direction ourselves.  The kick-start needed on change within the teams had already been made. (far more effectively than we could have achieved alone). 

With our leadership trust established, after being holed up in a tower for too long, our coaching team were able to reach the real world again. This time it was entirely within our own control, with the management support we needed and enough credibility remaining with the teams we had interacted with to move forward.

We were free, able to step in, learn more, tune, help out and spend months at a time properly embedded on teams taking them forward – reaching that point of empowerment for our team was a coaching journey in itself.

If you’re in the fortunate position to be an agile coach or in a similar role in a very large or more traditional organization, make sure you recognize that your coaching efforts will often be as much (if not more) necessary in coaching your leaders first.

One thought on “Rapunzel’s Ivory Tower

  1. Pingback: The Pitfalls of Measuring "Agility" | The Agile Pirate

Share your thoughts...