Category: Agile Congruence

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…

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…

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…

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…

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…

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…

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…

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…

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…