Posts on Agile Congruence

Introduction to Agile Congruence

Thu, 03 Apr 2025 13:30:54 +0000

One of my responsibilities at my former employer was to give an introductory talk about the Technology Team and our SAAS platform to new hires. This is always an interesting experience because of the diverse range of backgrounds in the audience. Accountants, Financial Analysts, Developers, and new graduates among others will all have very different levels of understanding of modern software development processes. After one such Intro to the Technology Team talk a newly hired Product Owner came up to me and said, “That was interesting, I’ve never heard anyone describe Agile Software Development as an Organizational Change process before”. That comment really made me think. Could my conceptual model of the process of building enterprise software help other organizations?

A Brief History of Agile Software Development

Thu, 03 Apr 2025 13:32:34 +0000

In the 20th century organizations viewed software development investments as projects. They would plan the project, document the requirements, implement the software, test the software, then release the software. While this process made sense on the surface, a lot of the software that it produced failed miserably after it was released. Processes that follow this development model are now labeled Waterfall.

In the early 21st century there was a great shift in enterprise software development. In February 2001 a group of 17 leading software engineering experts met at a ski lodge in Utah to discuss the state of software development. What emerged from that meeting is called the Agile Manifesto.

The Nadler-Tushman Congruence Model

Thu, 03 Apr 2025 13:34:02 +0000

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.

Releasing Software as an Organizational Change Process

Thu, 03 Apr 2025 13:54:01 +0000

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.

The Agile Congruence Framework Overview

Fri, 04 Apr 2025 17:13:15 +0000

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.

The Agile Congruence Framework Part 1

Fri, 04 Apr 2025 17:13:29 +0000

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.

The Agile Congruence Framework Part 2

Fri, 04 Apr 2025 17:13:41 +0000

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.

The Agile Congruence Framework Part 3

Fri, 04 Apr 2025 17:13:51 +0000

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.

Bad Software or Bad Organizations

Fri, 04 Apr 2025 17:14:00 +0000

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.

Conway’s Law and Agile Congruence

Mon, 07 Apr 2025 18:40:27 +0000

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.

This might kill your vibe, but I’m not worried about AI replacing Software Engineers

Wed, 23 Apr 2025 14:04:34 +0000

I started learning to code in the late 1990’s using gcc, make, and emacs.

The 2000’s were a huge pivot point in Software Engineering. Three major changes which were very related came together to fundamentally change how software saw built. First, modern IDE’s changed how coding was done. Second, high level languages like Java, C#, and Python became more usable. Third, agile fundamentally changed the way that engineers worked with businesses.