It's All About Culture - Right?

It’s all about culture.

That is the general consensus today with respect to agile transformation. But what is the “culture” of an organization? It’s certainly not styles of dance, or music, or food – some of the things that make up culture in society. So what is it?

Certainly this is not "corporate culture"!

An A. T. Kearney analysis defined corporate culture as a set of systems and practices enveloping behaviors, emotions, and interpretations. Systems and practices such as strategy, goals, measures, org structure, rules and procedures, rewards and recognition, mission statements – these all serve to drive perceptions, attitudes, and behaviors that in turn push back to reshape the systems and practices in a co-evolving cycle.

If its all about culture, then how do you change culture?

The ADKAR model developed by Prosci is one of the most widely recognized models for organizational change. It is closely related to the Prochaska & DiClemente “Transtheoretical Model”, also known as “TTM” – a model of behavioral change that is widely used by psychologists for individuals and for organizations. There are many others as well, but most of them posit a series of phases that the organization (or individual) tend to naturally go through, during which they first develop an awareness for the need to change, followed by a desire to support the change, followed by increasing knowledge on how to actually begin to change, and then followed by sufficient change that will be self sustaining.

I have seen this pattern play out in my own work with organizations. It has taught me that transformation takes time, and that one must set one’s expectations and plan one’s work based on these natural phases.

So how do you get things going? Where do you start? First of all, it is important to realize that change must address the range of factors that drive the current behaviors. In terms of a cultural model, you must identify the various elements of the culture, and find the “knobs” that you can turn that will push things forward, depending on where you are in the natural cycle of change: i.e., which “phase” you are in. For example, if you are in the beginning phase, in which people are merely considering whether agile is right for them, then it does not do much good to try to educate them on advanced technical practices: most people will not be willing to invest the effort required.

First and foremost you should talk to all of the managers and the teams to understand how things work currently, what people’s attitudes and plans are, and to identify the impediments to change. That gives you a set of obstacles something like what I presented in my prior post.

But that is only a sliver of the picture. These obstacles are not root causes. They explain things on a tactical level, but not on a cultural level. That is, they don’t explain why these obstacles exist, and what is keeping them there. To analyze the obstacles to determine root causes, it is helpful to think in terms of the culture and the places in which culture operates.

Martin Proulx of Audacium has proposed a 5 level organization agile maturity model – Yet another Agile Maturity Model (AMM) – consisting of five levels: Team Level, Department Level, Business Level, Project Management Level, and Management Level. His claim is that change needs to happen at all of these levels. This is an excellent model, and you might choose to use it, but I prefer to use a slightly different one, consisting of Team Level, Process Level, Functional Level, Executive Level, and Senior Executive / Strategy Level. If one lists these levels side by side with the systems and practices that drive behavior, then you have a picture of the nobs that you can turn, and where you might turn them, in order to adjust behavior over time. This is shown in the figure below.

As PDF: click here.

It is important to realize that many of these things must happen in parallel, and so transformation is not step-wise. Different groups reach “maturity” at different times, and you need to be plugged into them all. Change is messy: different parts of the organization do not progress together. Execution is in the details, and execution is everything.

One more thing: this picture is not a sufficient model for your organization’s behavior: it is only a kind of menu. To create a more useful model, you have to identify the actual behaviors, and the actual causes by asking the “Five Whys” (discussed in my priori post). The picture I have presented is only to help stimulate your thinking when creating your model. In fact, both the list of behavior manifestations and the organization tiers are generic – you should try to customize these to better match your own organization.

We are now ready to look at the root causes of the obstacles that I presented in my prior post – that’s where we really get into some substance. I’ll save that for next time – this post is already too long!

The Top Impediments To Agile Transition

Management’s first inclination when transitioning to agile is to train development teams on agile methodologies such as Scrum, and to bring in agile coaches to help the teams to transition. While these are important steps – indeed critical steps – these are insufficient: they are analogous to giving the members of the US Congress training in conflict resolution in an effort to improve Congress’s function: better knowledge of conflict resolution is always helpful, but the systemic and deep rooted issues that are causing conflict will resist change unless they are dealt with head on – perhaps through major political or structural change.

In the article “Most Impediments Are Management Level - Not Team Level” we explained how most of the obstacles to realizing the agile vision in an organization are rooted in management level issues – from culture and skill set issues to policy and leadership issues – and if these are not dealt with then the development teams will find it almost impossible to function in an agile manner.

We thought it would be useful to draw a map of the common impediments. When drawing such a map, however, one must be careful to differentiate between immediate impediments and the root causes that drive the impediments. Those who are familiar with the “Five Whys” concept know that root causes often are systemic and rooted in culture and tacit behavior that is far removed from where the problem actually shows itself through some symptom or obstacle. The “first why” is merely the immediate cause of the symptom that is being identified as a problem or impediment.

The chart below illustrates many of the common impediments that show themselves during an agile transition. Notice that most of these impediments are management issues: that is, in a large traditional IT organization it takes management to solve them for the whole organization - i.e., management must change things in order to enable agile to operate.

The impediments in the chart are “first whys” – they are not root causes. In a future post I will delve into each of the impediments and examine the root causes.

As PDF: click here.

How do we get there?

How do we get there?

That is, How do we make our IT organization agile? This is the critical question that is so often overlooked. And that question is what this website endeavors to answer.

We created this site because this question desperately needs attention. There is so much written on agile, and on “scaling agile”, and increasingly on what an agile IT organization might look like, but so little that answers the question of how to bring a large, established IT organization forward, to transform it into one that uses agile practices. Even those sources that address “scaling agile” do not fully address the problem, because the problem is not so much one of scale, but rather is one of organizational transformation.

Why make so much of this? Can it be that hard? In What Is Agile Transformation? we talk about why agile transformation is so hard, and why it so often goes off the rails. In Agile Transformation Is a Major Org Change we explain why it must be approached as an organization change - and not merely a scaling up of agile project coaching. In the business community we often hear of “crossing the chasm”, and in the agile community we hear a-lot about the Satir change curve. These are essentially the same model when you apply them to an organization, and they each provide a basis for explaining why agile transformation can so easily get bogged down when one tries to scale up pilot agile efforts to an entire organization. Agile - to be successful - requires changing how every single function in an IT organization works, and some functions beyond IT (e.g., procurement).

There are many established models for org change. Indeed, the field is fairly mature. (Here is a survey volume.) That is why this site brings together professionals from the fields of org change and agile, to synthesize those ideas. This synthesis is greatly needed.

In order to treat agile transformation as an org transformation, we need to move from the software team level up to the executive level, and at that level we need to speak in business terms - not agile project terms. Thus, instead of the vocabulary of agile - “sprints”, “velocity”, “stories”, “product owner”, “fail early and often”, “being agile versus doing agile”, and so on, we need to refer to business models of these same ideas, and there are many. Rockefeller Habits. The ideas of Deming. Drucker. Kotter. Covey. Jeffrey Hiatt. Clayton Christensen. James Scouller. Patrick Lencioni. Bob Sutton. William Bridges. John Hayes. Chris Agyris. Bill Quirke. Tom Devane. Spencer Johnson. Jurgen Appello. Hertzberg. The list goes on and on. We need to speak to these ideas, in these vocabularies, to be in the best position to offer agile ideas to management.

One of the thought streams that is rising today is “devops” - the idea that one must treat software development as a continuous pipeline that extends from conceptualization of a need all the way through business and IT operations without pauses. Devops essentially applies agile ideas to the entire scope of all activities that intersect with software development and the operation of production software applications. As such, it raises the bar for what organizations can and should accomplish in their quest to adopt agile, and it depends on org change even more to be successful.

In order to properly cover this vast range of topics, we have assembled an editorial board that covers these areas, as well as an advisory board of thought leaders in org change. We will have articles by guest authors with interesting and ground breaking points of view on a regular basis, with occasional articles by editorial board members. Please feel free to comment on the articles or other content - commenting is open to all.

We hope that this site helps to move the ball forward in the game of agile transformation. We hope to help you to learn how to better achieve a learning organization. We hope to enable agile and get you over the chasm!

Very best regards,

Cliff Berg
Chair, Transition2Agile Editorial Board