. .

Software Architecture is a Social Activity! Conways Law

A piece of software will always reflect the social structure it was build in.

Any organization that designs a system will inevitably produce a design whose structure is a copy of the organization’s communication structure.” (see Conways Law)

This has basically two consequences for agile software development and software development in general: (1) Either we accept that the software will have an architecture, that is a mapping of the current organizational structure, or (2) we need to change the way the organization is structured.

Some agile and Scrum consultants do want to implement feature teams to have organizations be more “agile.” The idea is, that a feature team will enable a more robust and more modular architecture. Teams can be more proud on what they have build and the features will be more independent from each other.

One problem with going agile in legacy environment is that the organization maps the architecture of the software. That means the communication is perfectly aligned to the organizational boundaries. Going agile in such environments is so hard, because the communication structure maps perfect the architecture of the existing software. By going agile, we “break” the working, but dysfunctional, structures — meaning the communication flows needs to be established differently.

Understanding this better in future, will help agile consultants to be more effective. First change the communication structure, than the architecture will follow.

Avatar of Boris Gloger
„Mut“ ist jener Wert von Scrum, mit dem sich Boris Gloger am stärksten identifiziert. Er hat in seinem eigenen Leben keine Angst vor radikalen Entscheidungen und vor dem Glauben an eine Idee. Für kein Geld der Welt würde er sich Regeln unterwerfen, die keinen Sinn machen. Er glaubt an Scrum, weil es nicht nur bessere Produkte, sondern auch eine bessere und menschlichere Arbeitswelt schaffen kann.
  • http://danielwildt.blogspot.com Daniel Wildt

    Good one Boris, I agree with you.

    When we start building an Agile team the software architecture changes, because of the “new” communication mindset we need to have. Actually, the new culture the team needs to accept.

    Most of the teams I worked with were doing Ad Hoc development, not following a specific process or methodology (or trying CMMI, UP, because they read in a book), but what I could find in those were communication issues. Big ones. Those resulted in defects, bad requirements, bad testing, bad coding…

    So the software architecture now has to take care of different types of testing and how the architecture is improved, how the architecture will accept new requirements. The way we gather requirements will change, the focus on risk management too, all because of the change in the communication process.

    I think architecture design and definition can get a lot more effective, if we are working in an Agile environment.