Conway’s Law meets Lean/Agile

“Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.” – Melvin Conway, 1968

You’ve probably heard of Conway’s Law in the context of system architecture and design. The architectural blueprint of a system tends to mirror the layout of the group that built it. Conway noted in his paper that the concept has much broader scope than just software systems, as it can be applied to any type of “system”. It’s a sociological observation, not a technical one.

If you overlay your company’s organization chart on top of your development process diagram you can see that Conway’s Law applies in a different kind of “system”. We can state a corollary of Conway’s Law as

“Organizations which design processes are constrained to produce a process flow which is a copy of the communication structures between departments”

Image

Try it. Map out your own organization and see how well it matches the phases of your development process. You should get a close enough match between departments and process phases to convince yourself that it’s not a coincidence. Functional departments are formed around technical domain expertise (e.g. Software, Hardware, Test), and the development process phases align with those boundaries. It doesn’t matter which came first – the process or the organization. Whoever framed up the process probably didn’t set out to create this match, it’s just a natural consequence of Conway’s Law.

So if the development process and the organizational structure are so closely matched, then what happens when we introduce Lean/Agile which has a fundamentally different process flow?

You already know the answer – friction and discomfort. Departments are typically preoccupied with their own internal and local efficiency. Lean/Agile is concerned with the overall end-to-end global process efficiency. The two rarely align. Departmental sub-optimizations are in direct conflict with the Lean/Agile flow.

So… Agile means a new organization structure?

The “straightforward” remedy to fix this conflict is to re-draw the organizational lines to line up with cross-functional teams rather than departmental domain expertise. Unless you are ready to push the reset button on many things that currently aren’t broken, this is not a great option. In an entrenched organization it will be a very upsetting and difficult thing to do. If you have the power, guts and the ability to actually do this, it might be the way to go. But for the rest of us (the 99% majority) we will have to be a bit more pragmatic about it and try to preserve the things that actually work, not drive good people away.

Good people should not be threatened by Lean/Agile

Some level of change is necessary when you move to Lean/Agile, and the new system is threatening to the old system. Sure. But remember if Lean/Agile is threatening to the organizational structure, there is no reason it should be threatening to the organizational managers. These are good people who have brought the company to where it is today, and if they can transition into a Lean mindset along with the company then that’s a big win: we can retain a lot of valuable experience and knowledge which simply can’t be found in a new hire.

Most of the people I have worked with over the years have the ability to re-tool and engage with the Lean/Agile model. Those who can’t or won’t tend to have a stressful time and it is not fair to ask them to work in a way that creates discomfort to them. That would violate Lean’s pillar of “respect for the individual”. Find other meaningful positions for them if at all possible, but for the good of everybody involved: don’t put them in an authority position (or even support position) on an Agile project. Here they will do more damage than good, and stress themselves out in the process.

Department heads are excellent domain experts

I find that in an R&D organization the department head typically has a lot of knowledge and experience in their technical domain. These folks are great resources! Thinking about departments as “centers of excellence” who provide skilled staff to the cross-functional teams instead of compartmentalized workshops is perhaps a way to reconcile the need for functional organization with cross-functional Agile teams. In that model there is still room for a “software organization”, a “test organization”, a “verification organization” and so on.

Image

The last thing we want to do is to sacrifice the continuity of technical domain knowledge simply in order to form cross-functional project teams. Someone needs to move the individual disciplines forward, identify and close skills gaps, provide coaching, keep up with technological advances, ensure the right tools are in place and so on. In such a setup there is a meaningful place for the departmental manager. Department members may be assigned to cross-functional Agile teams (even for the long term) but they always have a home base and an identity based on their technical domain skill set, and they have somewhere to go for help and advice in their discipline.

It can be a win-win to preserve the organizational structure and have the departments contribute their value-add to the Lean/Agile process. Most people will do good work if you let them. It’s better to join forces with department heads in established organizations. They are great allies, and as you jointly start to deliver Lean/Agile projects the sun shines on everyone involved.

At some point the atmosphere may become more relaxed and the option of drawing organizational boundaries closer to the cross-functional team structure may become more attractive. That’s a much better position to re-organize than at the start of a Lean/Agile transformation – but it requires patience.

Advertisements