Culture follows structure

"Culture is the product of the system; change the system and behavior changes" (John Seddon)

As a community, advocates of agile often seem preoccupied with the notions of culture and mindset. Even when people who have been involved in successful transformations actually talk about structural changes, they tend to refer to it as “changing the culture” - for example in these presentations by Mirette Kangas and Fred George.

This emphasis on culture paints the picture where “if you just change hearts & minds and train everyone, self-organization happens and things fall into place”.

But the driver for real change is not culture but structure.

My journeys in enterprises have taken me to places where seemingly everyone was trained in “agile” but as the key structures remained unchanged, the impediments persisted.

In one organization, “Done” did not mean that something was deployed and running in production. Done merely meant that the feature had been handed off to the Q&A and release organization. And as there was no easy way to measure the time in the Q&A and release phase, they measured the time spent in the development phase and called it the ‘lead time’. As we pointed this out and went on to explore this further, we discovered that for features that had been developed in 1-2 months, the total lead time could be as long as 18 months.

Another common example of a structural problem comes from contractual issues. In one organization, the people were excited about the new ways of working, and most had been trained as well. But upon asking if they could mix the current, component based teams to form cross-functional feature teams, the answer was a disheartened sigh.

After a bit of prodding, it was revealed that because of the outsourcing contracts in place, this was considered impossible. Moreover, the outsourcing had resulted in a considerable amount of offshoring. This had led into people on different sites specializing further into certain kinds of tasks. Because everybody had to have something to work on, prioritizing according to highest customer value was not possible.

And as the people who were responsible for the contracts did not feel the pain, nothing was done about these issues when the contracts were eventually renewed.

You can’t change structure bottom-up

Organizations tend to grow so that when problems occur, specialists are hired to take care of them. Over time this results in organizing such specialists into their own resource pools. Then work gets done by handing it over from one pool to another. Such structures are in direct contrast with the notion of cross-functional feature teams and organizing around delivering value to the customers.

In my experience, the drive to adopt agile often arrives at organizations at the level of development managers and team leads. However, the prevailing structures can only be changed by C-level executives, and hiring a “VP of agile” will not be enough.

Take it from the thought leaders

It doesn’t help that currently the most popular framework for scaling agile, SAFe, is not that explicit (at least compared to the total amount of material in the framework) of the need to change the structures. Examining the structures lurks under the notion of “applying systems thinking”.

To me SAFe has seemed almost surprisingly agnostic about the matter as it allows “development value streams” and says that “there is no one right answer”. The fine print does warn though that with development value streams you will end up with a lot of dependencies.

I had the chance of discussing this with folks from Scaled Agile Inc. They consider it a conscious choice: it's better to get a foot in the door and then proceed to help the client from there instead of getting completely turned down as a result of proposing radical changes up front.

While that may be true, there are thought leaders who criticize SAFe from SAFe from the point of view that because of the sheer amount of material, it can easily turn into scaffolding for the legacy organization to hide behind.

Also some thought leaders have taken the notion of changing the structure as a central part of their teaching. In fact, they consider the preoccupation with culture as failure demand caused by the inability to change structures.

They articulate this so well that I’ll step aside here and provide a few pointers so you can delve deeper into the matter.

The ones I’ve raised here work quite well even if you only listen to the audio, so you can explore them while for example commuting. These speakers have also lot of other presentations available on Youtube which further deepens the point. Here’ I’ve tried to pick those presentations that most directly cover the point I’m trying to convey and put them into an order they are most easily approachable. Enjoy!

Four presentations worth checking out:

• Mike Cottmeyer (2017): Is culture really the issue? (Youtube, podcast)

“Most organizations are deeply flawed from the perspective of delivering value. Teaching them to want something is not enough. At some point you have to do the work of removing the impediments. And if the impediment is 2M lines of legacy mainframe code in a key business system, you just can’t go and get it fixed by the next sprint”

• Craig Larman (2016): More with LeSS: a decade of descaling with LeSS @ Agile Munich meetup (Youtube)

“I can quickly spot a young naive change person when they say you have to change culture; you can’t change culture”

• Jason Little (2017): Rethinking agile transformation @ Agile Montreal (Youtube)

“Co-optation is the most common mode I see. A VP of agile is hired, the structures persist, we do things as we always did them, and the agile is put in front of everything.”

• Dan North (2017): How to break the rules @ Goto 2017 (Youtube)

“In companies we have a huge number of rules to cope with the limitations of the old way of working. In a transformation we not only have to dismantle them but also come up with the new and mostly very different kinds of rules to manage the new limitations"

• James Lewis: How I Finally Stopped Worrying and Learnt to Love Conway’s Law @ GoTo 2015

"The thing I most worry about is not testing, deployment or versioning - it's organizational design"