Organizational Change

The Nadler-Tushman Congruence Model, shown below, was introduced in 1980 in an article in the journal Organizational Dynamics. This model has gained great popularity in the Organizational Behavior community and is commonly taught in graduate Business Administration programs. The model begins with a set of inputs. These inputs are thought of as outside of the control of the manager of the organization under analysis. The manager is given a strategy. Even if they were part of the development of that strategy, it should be given before the change process. They also have a fixed set of resources and are working in some known environment. ...

The key hypothesis of Agile Congruence is the relationship between releasing software and the Nadler-Tushman model. Enterprise software is the automation of an organization’s formal processes. Each time an organization releases software, it changes the “work” component of the organization in the Nadler-Tushman model. With each software release the people, culture, and org structure components must then be evaluated and possibly updated to keep congruence in the organization. This means that the working software output of the agile software development model is a change in the work component of The Nadler-Tushman model. Under an Agile software development methodology, these changes are made frequently. At the company where I spent the majority of my career we released software every two weeks. In order to maintain congruence every two weeks we needed to evaluate the impact of the released software on the people, culture, and organizational structure components of our business. While this seems daunting it results in a series of small incremental changes and it is far easier to implement than the alternative of making large organizational changes every six months to a year. ...

In their paper A model for diagnosing organizational behavior, Nadler and Tushman define a process for implementing their change model. In that spirit, Figure 3 shows an overview of the process for using Agile Congruence to implement a software driven organizational change process. While I use these steps when implementing technology changes, I don’t go through a formal documentation process. This process can be accomplished with a whiteboard or two, an Excel spreadsheet, a PowerPoint, or whatever tools you use to best organize your thoughts. Many organizations use tools like Jira or Gitlab Issues to manage their backlogs, but other tools like Post-It notes or Excel spreadsheets work fine as well. I would be very sad if I saw an organization produce a binder of documentation formally documenting this process. ...

1. Identify Symptoms There is some reason that your organization wants to change and make an investment in technology. In the past when I have assumed that all stakeholders were on the same page with the problem that we were solving I was usually wrong. Taking the time to identify and understand the symptoms and ensure that there is agreement among stakeholders on the problem statement is a key first step to scoping your change process. ...

4. Analyze Gaps and Build your Backlog In the process laid out by Nadler and Tushman this phase was labeled Identify Problems. In the world of agile software development these problems are captured using tools like User Stories. Modern UX techniques can also be used to help with this Analysis. At Chatham, when facing some complex organizational changes, we use the concept of a Design Sprint to guide users through a problem identification process and capture the gaps in the current organization. Each organization typically has a different process for accomplishing this and there is a wealth of information in the software world on various processes that your organization could implement. ...

8. Decide to Continue or Re-Evaluate At this point on any iteration you may find that there are no changes that can be made where the value of the change justifies the cost. There are times early in the process where we have found that we should delay development and wait for other organizational changes to complete before we make the investment in software, and other times late in the process where we have a set of nice to have features that are expensive to implement and provide lower value. In either case, at this point you should delay or cancel further development on this project, as more software will not deliver more business value. ...

There are many definitions of bad software. Clean Code’s metric of WTF’s per minute, test coverage, cyclomatic complexity, and a million other measures can be put in place to measure good vs. bad software. Through the lens of Agile Congruence I want to offer yet another definition of bad software. Bad software is software that changes slower than your organization. In an organizational change process, you will encounter a lot of resistance to change. Organizational structure changes require buy in from many stakeholders. Culture changes require discipline of your team. People changes require a willingness to learn new skills. If your biggest impediment to changing your organization is that your software team says that the delivery of the required features is too difficult, you have bad software. All development organizations have technical debt. This debt needs to be managed and invested in to allow your organization to have the speed and flexibility to change. ...

In a recent discussion with a fellow Software Engineer about Agile Congruence, he stated that the model did not consider software architecture. More directly he said, “I can be effective at agile software development and delivering in small batches of changes but if my architecture sucks it still might not let me be agile enough.” While I definitely agree with this statement, it got me thinking about how Agile Congruence and Software Architecture are related. Ultimately I realized that this comes down to one of the most famous principles in enterprise software architecture, Conway’s Law. ...