The Borg ‘assimilate’ - they draw you into their structure physically and mentally. Your needs are subordinated to the structure itself. Resistance is futile. Sound like a typical corporate change programme?

TL;DR

Execution is a more effective narrative than culture change for Agile adoption. Create an organisation that embodies those behaviours that were successful at getting software into the hands of your customer. To do this, you need to observe the end to end process of delivery across teams and not just focus on intra-team agile practices. Take the time to watch these processes in your organisation as you start a couple of agile projects. Don’t re-organise until you have seen several iterations of software get to production.

Structure and Change

There has recently been some discussion online about organisation structure and DevOps. A good article by Rob England is here.

An issue that I confront quite often with my clients is an almost preternatural need to re-structure for DevOps or Agile (pick one, both or another buzzword) before actually having used the approach in practise.

IT executives confide a variety of reasons for this. Some believe that the current organisation structure will kill any change that requires new ways of working. Others cite the need to get resources - people, infrastructure etc. - to control the progress of the change itself or just to create an environment in which new skills are developed. These reasons reveal both cultural and execution concerns. How do I bring the staff along with us on this journey? Will this actually help to resolve current challenges in IT today? How long have I got before my peers start to challenge my progress? All valid, pragmatic concerns.

I put IT change strategies into two broad categories:

  • Emphasize culture & behaviour, in the expectation that it enables execution, or the realisation of concrete benefits.
  • Emphasize execution, believing that a focus on delivering results will bring the required culture and behaviour change along with it.

Culture and Memory

You might object to this as a false dichotomy. For any new technology or approach to be successful we need to see positive results. If a new technology requires us to work in a different way then we need to enable these new behaviours to get the results we seek. The fact remains, organisations tend to focus on one more than the other.

My rather instrumental definition of culture is, “The way we do things around here.” Although this might appear rather a naive definition, we find people defining their corporate culture this way all the time:

“We always start meetings 5 minutes late!”

“If Ellen has childcare issues she should work at home today.”

“There is no way you will get that through the CAB without lobbying Allan first.”

In this definition, we observe culture through behaviour. In some cases, those behaviours frustrate the best intentions of the company. Culture is not independent of execution, it creates the environment within which it flourishes or dies. However, culture is also the organisation’s memory of what has gone before. Teams quickly learn that collaborating across a process boundary without taking care to meet their team specific targets will get them into trouble.

“I would love to help you out, but you need to raise a ticket for that.”

“I told them the product had no hope, but they don’t listen to me. I’m just the developer.”

This simple insight leads me to believe that in order for culture to support any change, such as the introduction of agile methods, it needs to tap into some new memories of how things are done.

I see companies that consider culture of primary importance (as per the definition above) often move to re-structuring early on. Like culture, structure is also a form of organisational memory. Following Conway’s Law, we know that organisations will create systems and processes that reflect their structure. Over time, those structures become legitimised and create a cultural ground for the company itself. An interesting and disturbing test for this is to ask, “How do we trust?” in our organisation. After the usual veneer is removed we hear that trust is replaced by ideas of ‘‘separation of concerns’ or ‘‘trust but verify’.

The issue is this: Structure shapes behaviour. Behaviour shapes culture. But what if you don’t know what behaviour is required?

Behaviour and Execution

When it comes to implementing Agile techniques, the advice that most companies receive will be to start using the approach in a small localised way and to then scale that capability across the organisation once some competence has been achieved. Sounds fair enough.

From a few examples in early adopting teams, it is easy to observe how the ways of working are different. It is seductive. The IT manager feels that s/he has ‘‘got it!’ We know how to do this now. But observing the new behaviours is not enough to provide a basis for creating new structures. What we see when organisations structure too early are teams and processes that use the terminology of agile and act to protect or legitimise the new practice. An example is the simple idea of the scrum team. We create teams, buy kanban boards and beanbags, and focus on the behaviour inside the team.

Structure has its effect between teams. The most important behaviours for an organisation to watch in early implementations of Agile are those between teams, and between the new agile teams and the existing traditional teams and processes. This is different from the core behaviours we think of when we consider the agile mindset or when an IT Manager watches a good scrum master run a team.

When we consider the success of an agile initiative in traditional enterprises it is always due to effective inter-team working.

You need to watch an idea pass from someone’s head to become software in a customer’s hands and back again for refinement. This behavour is the birth of agile in your organisation.

Get to Production!

I often see organisations implement agile without actually accelerating the delivery of software to the customer. If you are not delivering software to learn about its suitability for the user then you are not being agile. Agility at its core is about exploration and learning. This requires regular updates to the functionality delivered. If you deliver software in 2 week sprints that accumulate to create large quarterly releases then you may as well use waterfall.

This lack of feedback from the customer becomes entrenched quickly. Scrum teams begin to think of the internal function of the team as the end in itself. Many observations of the process of creating software and obtaining feedback on it are required. This is how to understand what structure will best support agile in your organisation.

The best practise that I have observed is the identification of a couple of projects that will iterate over a well defined set of user requirements and an obsessive focus on getting what is made to production. Everything you need to know and understand about agile comes from an investigation into where friction exists in this process.

Agile coaches have many tools and techniques to help you address the issues you find. Team communication and product prioritization are common issues that you will encounter as friction in delivery. It all comes from working backwards from production!

Until you have experienced this, the informed design of an organisational structure is impossible. A sad reality though is that for most IT managers, failure in this respect - arrogantly pushing forward with structure before knowledge - has few consequences.

“Yeah, agile is tricky… maybe it isnt for us after all. Our organisation has some unique challenges not found elsewhere.” Sigh. Often, the IT Executive is long gone by the time reality hits.

These IT Execs are like the Borg Queen… my structure is perfect and final. Even if they say it isn’t. “oh no, we’re still learning..” what they mean is that they’re done learning and the rest is just computing the size of the cube.

Solving the ‘‘unique’ problems of your organisation is the basis of organising for Agile.

Finally, Execution and Structure

To return to the change strategies introduced above: Execution is a more effective narrative than culture change. Execution - of code to production - creates the circumstances you need to observe the organisation in action. You will create an organisation that remembers those behaviours that were successful at getting software into the hands of your customer. And that’s an agile culture.