Put Conway’s Law to your advantage

Without freedom of movement, the course of people within your organisation is restricted to your general direction. As in the name, the true promise of agile software development isn't the rebranding of your project management department to Scrum counterparts. No, the promise of agile is for a business to move easily and quickly in the (potentially multiple) directions it has to take. Iteratively releasing in shorter timespans enables you to take finer-grained steps in discovering and applying your strategy, allowing you to reach the fast-changing requirements of your customers in shorter feedback cycles.

While you can perform these iterations in a single team – in a sequential manner – the real strength of iterative software development comes into play when you're able to do this in parallel, with success, over multiple self-organising teams. This, however, is not only a "people" thing. Technology and systems play a far more critical role than people often think.

"Any organisation that designs a system will produce a design whose structure is a copy of the organisation's communication structure."

Conway's Law (Melvin Conway)

Autonomous work environments

Self-organising, autonomous teams aren't created by placing them in different rooms, giving them different product owners, and giving them isolated Slack channels. Communication boundaries between teams are essential, but autonomy is difficult to reach when the same principles aren't also reflected in the actual system in which your organisation is applying its expertise.

We've seen many environments where Scrum is pushed through an organisation as a saviour for long development cycles — eventually seeing the sprints spiral to five weeks. The first week is to coordinate which parts of the system will be touched, two weeks of development and finally two weeks of organisation-wide testing to see if nothing got broken along the way. Agile teams? Maybe. Agile delivery? Not so much.

Melvin Conway once described the "Conway's Law" in which organisations design systems that are copies of their communication structures. Highly aligned development iterations also show that the reverse of Conway's law holds: organisations tend to follow communication structures which are a copy of the systems they're working in.

Most implementers of agile agree with a team's optimal size and form. When a team is too small or no mandate is available, not enough work can be done in an iteration or sprint. When a group is too large, too much overhead is created to accomplish anything. Far less focus is, however, placed on the size, form, and even mandate of the environment teams are working in. When is the size of that context too fine-grained and too small to deliver any business value, and when will the size of their environment impact their actual productivity through cognitive overload?

Many companies only think about agility from a team and process side, creating a software architecture equivalent to the often despised open office spaces. A noisy, coupled, and often a monolithic system in which multiple teams have to work in parallel and isolation from a process level but are tightly knitted on a system level. Just like in an open office space, you think of rules to ensure the noise is on acceptable levels to ensure everyone can be somewhat productive. Yet, collaboration and knowledge-sharing is the exact thing you want to stimulate to enable your business to grow together with your working force's intellect.

The other extreme can often be over-modularity, in which you give your developers a go without aligning developed capabilities with your business departments. This often leads to a technological solution which is over-fragmented. Maintaining many services and responsibilities within a single team will increase the cognitive overhead to levels where productivity will quickly decrease.

Finding the balance is by using the dualism of Conway's law to your advantage: setting boundaries which are both defined on a team and organisational level, as system level. Taking a direction in which the correct level of modularity allows teams to discover, engineer, re-engineer and deliver in parallel with other teams while still keeping the headspace to collaborate on their relationships, dependencies and direction of the system as a whole.

Achieving the correct shape of these boundaries can be difficult. Still, like forming teams around business units and customer journeys, the idea of a boundary in a system should be approached through experimentation and agility.