Complexity in Change Management Processes

Added to The Alliance

by Jutta Eckstein, Diana Larsen, James Shore

In this work, we present the concept of a change model. The model addresses complex changes as we often experience it when introducing a modern (respectively Agile) software development process. The model enables change leaders to better understand the context of the change by looking at the change’s purpose, conditions and the possible change options. The model is still experimental, yet it has been tried with two different groups. In this work, we report on the one hand on the change model itself and on the other hand on our experiences using it with these two groups.1.

Initial Situation

At the end of 2011 the Agile Alliance invited thought leaders in the development of the future of Agile to a 3-­‐days Open Space Session on “Catalyzing Change in Complex Systems through Agile Adoption”. The idea was to focus on organizational issues when adopting Agile software development. On the first day, James Shore suggested an Open Space session, which was continued during the two following days and morphed into the topic “Developing a change model for Agile transformations”. A core group worked on this change model, James Shore, Diana Larsen and Jutta Eckstein2.

Objective

Agile software development is based on a value system and twelve principles which emphasize the importance of collaboration, feedback and continuous learning3. Switching to such a software development approach implies a change because it requests to develop software differently compared to a traditional process. For example, conventionally a test will be created after the software has been developed, whereas an Agile process asks for the opposite sequence. Yet, the change to an Agile approach affects the entire organization, i.e. in terms of team development or leadership style by its emphasis on collaboration and continuous learning and in terms of procedures with its emphasis on teams rather than individual contributors. Thus, although at first concentrated on the software department only, the change will have an impact as well on other seemingly unrelated organizational areas. As John Kotter put it:

“Without much experience, we often don’t adequately appreciate a crucial fact: that changing highly interdependent settings is extremely difficult because, ultimately, you have to change nearly everything.” (Kotter, 2012, pos. 1904-1911)

The model’s objective is to help change agents understand the context of the change they are in, provide support in determining the focus, and helping them to decide on an approach for the respective change.

Understanding the Change Model

The model is embedded in a greater framework and should not be used stand-­‐alone (cf. following figure). A change-­‐focused group, similar to a guiding coalition (cf. Kotter, 2012, pos. 698-­‐910) is responsible for chartering the purpose for the change first, so that the sense of urgency is understood and the vision, mission, along with the mission tests are defined (cf. Larsen & Nies, 2011, pos. 775-­‐801).

Framework for the Change Model (own illustration)

Next, the group is supported by the model in the succeeding three steps of the framework where questions help to understand the context. The so-­‐called Landscape Diagram will provide guidance for coming up with different change options.

Finally, the framework requires reflecting regularly on the charter and the selected approach, tracking the emergent conditions, and updating the model’s content accordingly. Thus the framework is not a step-­‐by-­‐step but rather an iterative approach.

Conditions and purpose as context of the change

In order to understand the context for any kind of transformation we agreed that we first have to look into the purpose and the conditions for the respective change. In terms of conditions we uncovered the following general categories which will be further explained with some examples of transformations in each case:

  • Social: Dealing with shifts in politics, interactions, and patterns as well as in formal or informal information flow.
  • Technical: Tackling transitions in infrastructure, operations, product and project development, operational systems or the physical plant.
  • Environmental: Addressing changes in the marketplace, with customers, geography, regulations, community or with the suppliers.

Thus, changing to an Agile development process might be environmentally motivated by the client, who requests more frequent updates of the software system. Yet the conditions surrounding the change might as well be perceived as a challenge, if in this example the current technical infrastructure doesn’t support more frequent updates.

Every change is driven by purposes that have to be taken into account. Along the lines of Doppler and Lauterburg, we defined the following categories for the change purpose (cf. Doppler & Lauterburg 2010) each one elaborated further for clarification:

  • Strategy: Where we want to go.
  • Structure: How we organize ourselves.
  • Culture: Beliefs, underlying assumptions, values. In other words – the stories we tell ourselves about ourselves.

For example, switching to an Agile development process requires customer-­‐orientation – however, this might contradict the organization’s strategy. Or relying on open and honest communication as requested by Agile processes might oppose the organization’s culture if this is based on secrecy and command and control.

Questions about the past, present and future

The two characterizations –purpose and conditions– define the first two dimensions of the change model:

Social

Technical

Environmental

Strategy

Structure

Culture

The change model showing purpose and conditions (own illustration)

We developed a set of questions addressing the past, present and future of the organization. These questions should help understanding the context of a change better by applying them to the cells, respectively the intersections of purpose and condition:

  • Past: Where have we been?
  • Present: Where are we now? How did we get here?
  • Future: What are our aspirations and fears about the future? What conditions need to be present?

These questions should additionally guide the change-­‐focused group in choosing the next change to concentrate on. It is up to the group to pick and choose a number of cells for elaborating the questions. Selecting the cells might be based on applicability, urgency, but as well on the group’s specific interest. For example, one group selected at the intersection of technical and culture the need to change the lengths of the release cycle4. By answering the questions about how long have the release cycles been in the past, how the group ended up with these currently long cycles and what conditions need to be present in order to reduce the cycle times, the group got a much better understanding about their possible next steps.

Different change options

For understanding what change options are available for the next step, we suggest a third dimension to the change model. This third dimension is based on the Landscape Diagram (cf. Holladay & Quade, 2008, p.29-­‐41 and HSD, online). This diagram is rooted in Ralph D. Stacey’s relationship between change context and decision-­‐making or control modes (cf. Stacey, 1996, p.47) and has been elaborated further to the Stacey agreement and certainty matrix (by Zimmerman et.al., 2008, p.136-­‐143).

Landscape Diagram (cf. Holladay & Quade, 2008, p.30)

The Landscape Diagram visualizes and relates the main human drivers for any kind of change. Depending on how certain we are regarding a specific issue and relating this on how much we are in agreement in respect to the issue under examination, we can conclude what change options are available.

Besides the fact that we can always decide to refrain from any kind of change, the diagram visualizes the following change options (cf. Eoyang and Holladay, 2013, pos.1044-­‐1198):

  1. Static: When a group is close to certainty and agreement then a static change is the most typical option. Because actions can be planned and controlled, this area is called the organized zone. Root-cause analysis with consequent problem solving, the application of best (or good) practices, Lewin’s change model of unfreeze- change-refreeze (cf. Lewin, 1947, p.34-36) or expert judgment are methods widely used for such kind of change.
  2. Dynamic: A dynamic change is required if a group is in complete agreement, but not completely certain, or if they are certain about the approach, but not in full agreement. This is the area between the static and the self-organized zones. Here adherence to rules is not appropriate yet adaptation is. Thus, in this zone planned change initiatives, leading change step-by-step (cf. Kotter, 2012), leadership or/and employee development plans or the application of expert processes will be helpful.
  3. Complex (also known as Dynamical): If a group neither fully agrees nor is fully certain a complex change is the consequence. Such a situation is emergent or highly unstable and unpredictable. The corresponding zone is either self-organized or unorganized. Change has to be iterative, thus incremental actions and seeking for emerging patterns are highly recommended. Example approaches developed for this kind of change are Revan’s Action Learning (cf. Revans, 2011), Argyris’ double loop and particularly deutero learning (cf. Argyris, 1995), Adaptive Action (see Eoyang and Holladay, 2013) or Cynefin (see Kurtz and Snowden, 2003).

Increasing constraints, e.g. introducing rules shift a situation towards the organized zone (and vice versa). Moreover, situations are not bind to a specific area and therefore no particular change option is generally advisable. For example, research and development happens typically in an unorganized zone, which is subject to complex change – creativity, exploration, experimentation are of high importance. Once an idea will be further examined, creating plans and prototypes shift the work into the self-­‐organizing zone where dynamic change happens. As soon as the idea turns into production, rules and regulations have to be followed. Therefore, the work will then be performed in the organized zone and static change will help reach the goals (cf. Holladay & Quade, 2008, p.32).

Thus, the presented change model consists of the following three dimensions: purpose, conditions and options for change (cf. illustration below). The example group (who wanted to change the lengths of the release cycle) analyzed how much they were in agreement about this necessary change and additionally how certain they were about their ability in shortening the release cycle. They concluded that they were very much in agreement but rather uncertain about the necessary change. Thus most likely a dynamic change approach will help the group to make the next step.

User Reactions

In order to verify the applicability of the model, we ran two workshops at two different conferences. For both workshops, we asked the participants to assemble in small groups around at least one volunteer, who is currently leading a change initiative and is willing to share his5 experience. While the volunteer was asked to share his story, the group had the task to collect the reported challenges, problems, stuck places and unexpected situations. Next, we presented the change model (excluding the different change options at this moment). The small groups were then asked to focus on the intersections between purpose and condition by picking cells of the model that apply and collaboratively answer the questions referring to the past, present and future of this change initiative.

Subsequently we introduced the Landscape Diagram and explained the differences between static, dynamic and complex change. The small groups had now to focus on one of the cell’s they have worked on previously and decide what change option is appropriate for that specific issue. The groups were asked to consider what they would need to address and how they could readdress the problem under examination.

In order to obtain feedback on the model, we used silent discussions. Thus we asked the participants to silently comment on the following questions presented on different flipcharts:

  • How does this model help?
  • What’s missing?
  • Where can you imagine applying it?
  • Where wouldn’t you apply it?
  • What other questions should we ask?

Although there was one comment stating the model is difficult to apply, most comments emphasized that it is easy to use, provides insights and clarifies confusion. The major point in favor of the model seems to be the clarification on what to focus on next. The biggest part missing (which we forgot to present in detail) was how the model is embedded in the larger framework. Thus, we regard identifying the change-­‐focused group and the chartering – defining the vision, mission and mission test– as essential preconditions for using the model, because:

“Agile chartering provides a critical link to purpose, alignment, and context.” (Larsen & Nies, 2011, pos. 280)

The model has been regarded as being particular applicable for complex change, where more people are involved and the change isn’t straight forward. One person summarized this point by saying that the benefit of the change has to be greater than the cost of the analysis.

The major open issue seems to be the timing aspect: What are suitable timeframes – not too small and too large – for inspection and adaptation. And then how to find out when it is more appropriate to address the issue right away and when it is better to just wait and see. Thus, the model might need to integrate a fourth dimension: time. For the moment the timing aspect is only taking into account by the questions referring to the past, present and future.

Conclusions and Future Directions

The model helps to clarify the understanding of the context of the change. By looking at the purpose and the condition and by elaborating on the questions about the past, present and future, the model supports the selection of the focus for the change. Furthermore, considering different change options helps to clarify which kind of change is more appropriate in the given circumstance over another kind of change.

Yet, the change model has to be used cautiously as we experienced when testing it with the participants of the workshops. Especially explaining how the model is embedded in a larger framework is essential. Without that explanation people tend to use the model as a recipe – concentrating on “stupidly” answering the questions for each cell and ignoring the vision and mission of the change as a whole. This probably leads to oversimplification of the change initiative. However, even explanation of the larger framework provides that risk, just because a model like this invites to reducing the complexity by breaking the change into smaller parts and categorize those parts subsequently. However, this usage does not leverage the full benefit, as Holladay and Quade point out analogously to the usage of the Landscape Diagram:

"To think of it as simply a way to categorize the work of parts of the organization is to miss the richness that is available in understanding it as a continuum of action and response that allows for adaptation to challenges as they emerge in the environment.” (Holladay & Quade, 2008, p.40)

Thus, the model isn’t meant for reducing complexity but for understanding it.

Moreover, the model is still in its infancy and we need more experience applying it in different circumstances before making any conclusions. Generally, we are certain that the more often we will use the model the more we will learn about it. And this learning has to be fed back into the model. Thus, like everything else – also this change model is subject to change, because:

“Learning and change processes are part of each other. Change is a learning process and learning is a change process.” (Beckhard & Pritchard, 1992, p.14)

Footnotes

1 This document is a result of the Agile Enterprise Adoption Program of the Agile Alliance Non-­‐Profit Organization and is based upon additional input by Ray Arell, Jens Coldewey, Esther Derby, Israel Gat, Michael Hamman, Jorgen Hesselberg, Bill Joiner, George Schlitz and Kati Villki

2 We were supported by a few more people, most notably at the beginning by Michael Hamman and Jørgen Hesselberg.

3 The definition of the value system and the twelve principles can be found at: http://agilemanifesto.org.

4 A release cycle defines the speed in which the software will be delivered to the client.

5 For better readability I’m using the masculine form only. However, this doesn’t mean that there were only male participants.

Literature

Argyris, C. and Schön, D.A. (1995): Organizational Learning II: Theory, Method, and Practice. FT Press.

Beckhard, R. and Pritchard, W. (1992): Changing the Essence: The Art of Creating and Leading Fundamental Change in Organizations. San Francisco, CA: Jossey-Bass.

Doppler, K. and Lauterburg, C. (2010): Management Corporate Change. Berlin, Heidelberg: Springer.

Eoyang, G. and Holladay, R. (2013, ebook): Adaptive Action: Leveraging Uncertainty in Your Organization. Stanford, CA: Stanford University Press. Kindle ed.

Holladay, R. and Quade, K. (2008): Influencing Patterns for Change. CreateSpace Independent Publishing Platform.

HSD (online): Human Systems Dynamics (HSD). Landscape Diagram. http://wiki.hsdinstitute.org/landscape_diagram. And: 3 Kinds of Change. http://wiki.hsdinstitute.org/3_kinds_of_change. Last accessed on April 15th, 2013.

Kotter, J. (2012, ebook): Leading Change. Boston, Mass.: Harvard Business Review Press, Kindle ed.

Kurtz, C.F. and Snowden, D. (2003): The new dynamics of strategy: Sense-making in a complex and complicated world In: IBM Systems Journal, Vol.42, No.3, p.462-483. Available also online: http://alumni.media.mit.edu/~brooks/storybiz/kurtz.pdf. Last accessed on March 22nd, 2013

Larsen, D. and Nies, A. (2011, ebook): Liftoff: Launching Agile Teams & Projects. Onyx Neon Press, Kindle ed.

Lewin, K. (1947): Frontiers in Group Dynamics: Concept, Method and Reality in Social Science; Social Equilibria and Social Change. In: Human Relations I. p. 5-41. http://hum.sagepub.com/content/1/1/5. Last accessed March 27th, 2013

Revans, R. (2011): ABC of Action Learning. Burlington, VT: Gower Publishing Company. Stacey, R.D. (1996): Strategic Management & Organizational Dynamics. London: Pitman

Publishing, 2nd ed.

Zimmerman, B., et.al. (2008): edgeware: lessons from complexity science for health care leaders.

V H A Incorporated (Curt Lindberg, Plexus Institute).

 

About the Author

Jutta works as an independent coach, consultant, trainer, author, and speaker. She has helped many teams and organizations worldwide to make an agile transition. She has a unique experience in applying agile processes within medium-sized to large distributed mission-critical projects.She has published her experience in many books. Most recently she co-authored (with John Buck) of ‘Company-wide Agility with Beyond Budgeting, Open Space & Sociocracy’ and (with Johanna Rothman) ‘Diving for Hidden Treasures: Uncovering the Cost of Delay in your Project Portfolio’. She is the author of ‘Agile Software Development in the Large’, ‘Agile Software Development with Distributed Teams’, and ‘Retrospectives for Organizational Change’.She is a member of the Agile Alliance (having served the board of directors from 2003-2007) and a member of the program committee of many different American, Asian, and European conferences, where she has also presented her work.Jutta Eckstein works as an independent coach, consultant, and trainer. She holds a M.A. in Business Coaching & Change Management, a Dipl.Eng. in Product-Engineering, and a B.A. in Education.

Diana Larsen consults with leaders and their teams to create work environments where people flourish and push businesses to succeed. She is an international authority in Agile software development, team leadership, and Agile transitions.Diana co-authored Agile Retrospectives: Making Good Teams Great; Liftoff: Start and Sustain Successful Agile Teams; and The Five Rules of Accelerated Learning. In collaboration with James Shore, she developed the Agile Fluency™ Model. Diana Larsen consults with leaders and their teams to create work environments where people flourish and push businesses to succeed. She is an international authority in Agile software development, team leadership, and Agile transitions.Diana co-authored Agile Retrospectives: Making Good Teams Great; Liftoff: Start and Sustain Successful Agile Teams; and The Five Rules of Accelerated Learning. In collaboration with James Shore, she developed the Agile Fluency™ Model. She is a past Chair and former board member (2007–2013) of the Agile Alliance Board of Directors.

James Shore teaches, writes, and consults on Agile development processes. He is a recipient of the Agile Alliance's Gordon Pask Award for Contributions to Agile Practice, co-creator of the Agile Fluency™ Model, co-author of /The Art of Agile Development/, and host of “Let's Code: Test-Driven JavaScript.” InfoQ has named him as one of the “most influential people in Agile.” You can find his screencasts at letscodejavascript.com, essays at jamesshore.com, and more about the Agile Fluency Project at agilefluency.org.

Agile Alliance is a nonprofit organization with global membership, supporting and serving the Agile software community since 2001. We support people who explore and apply Agile values, principles, and practices to make building software solutions more effective, humane, and sustainable. We share our passion to deliver software better every day.


This is an Agile Alliance community blog post. Opinions represented are personal and belong solely to the author. They do not represent opinion or policy of Agile Alliance.