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.
Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.
— Melvin Conway
Agile Congruence is a model for organizational change, and Conway’s Law is a major source of inertia in modern organizations. In the Nadler-Tushman model Org Structure, Culture, and Work all help define an organization’s communication structure in different ways. To change the architecture of a system you need to change communication structure, and to change communication structure you need to change these aspects of your organization.
Using the agile congruence framework, you can identify and correct issues caused by Conway’s Law. By looking beyond the work component and into the structure and culture of the organization, you can get a better understanding of why your outputs may not be at desired levels and take truly constructive steps to bring the organization back into congruence.
As an example, I was in a matrix organization with vertical teams aligned with market sectors, and horizontal teams aligned with cross sector disciplines. I was working with one of these horizontal teams. Over time this horizontal team had started to drift apart, with the sub-teams aligned with each vertical defining their own formal processes and culture.
My scrum team was working closely with our product team and really felt like we were delivering on the backlog. We were proud of our progress for several releases, until we got a huge surprise. Two of the sub-teams weren’t using what we were building. They were actively resisting. When they were told by management that they had to migrate to the new system, they told management that it would be impossible.
After a lot of digging it turns out that the parts of the system aligned with their vertical just didn’t mesh with the system we were building in the horizontal. Data formats, processes, and workflows were so different that it was nearly impossible to integrate the systems.
To break this, the company ultimately realized that the horizontal (my team) shouldn’t formally exist. This realignment was a tough pill to swallow at first. We had delivered great software that solved major issues, but in hindsight that “great software” was not properly aligned with the larger architecture of the company.
Realigning the horizontal team totally changed the organizations communication structure, and drastically reoriented the direction of the scrum team. After about a year in this new configuration the new system was fully adopted and both users and engineers were happy with the results.
Leave a Reply