More on organization structure following the thread I started yesterday. I probably won't get this finished today and it probably won't be totally coherent and thought through. It is after all a blog and not a serious article.

Yesterday, I talked about architecture and coupling and cohesion and object-orientation and distributed components and aspects and services, and how ideally we want a loosely coupled, highly cohesive organization mapped against our product architecture. This provides an encapsulation that is empowering to a team and leads to high productivity with low overhead. In Lean terms - less waste. However, the problem is that we don't do aspect-oriented organizations very well. Anything that has a cross-cutting concern tends to get bogged down in politics and negotiation over who owns it.

I'm not talking about matrixed organizations. We have that fairly set already. At Microsoft we have Program Managers (in the rest of the world you'd call us Project Managers) and resources from functional managers are matrixed to the PM to do projects - Features in products. This works nicely. The Feature Team is hopefully cohesive and loosely coupled through the PM as the communication point. But it doesn't work well when the Feature is cross-cutting of others. This leads to a lot of extra communication - waste - and slows things down.

There is a second problem mapping architecture to organization. Architecture has uncertainties at the start of a project just at the time when you want to lock the organizational structure. Furthermore, we tend to do architecture top-down and this usually means that we get it wrong first time and several iterations are needed before it settles down. This leaves us with an organization that is mismatched to the underlying architecture of the product with the resultant overhead of extra communication, uncertainty, several teams accessing the same code and a general slow down in productivity. While developing Team System v1.0 we saw just these kinds of problems. The MSF team was moved around a bit and parts of the process template and work item tracking were also moved as Rick La Plante looked for the best organizational structure to match the emerging architecture of the product.

However, there is a better way. Bottom-up architecture driven off a domain model has been shown to facilitate late definition of the component or service boundaries. This postponement of decision making fits with the Lean idea of making decisions at the last responsible moment. Bottom-up architecture solves the problems of top-down architecture and the rework and confusion it can cause.

A few years ago, I worked on a project at another company. I was leading the team in Seattle. The architecture was being done in Mountain View, CA. While the other development teams were in Beijing, Bangalore and St. Petersburg. The architects analyzed the system and then divided the work out between the four teams. What happened next? The teams spent months holding weekly global teleconferences to resolve issues with the interfaces between components and the roles and responsibilities between the teams. This led to poor productivity and lots of stress and confusion. A direct result of poor top-down architecture and something that could have been solved by bottom-up domain-driven architecture.

So here are the challenges I see still in organizational structure. How do you organize for the early lifecycle while you are building the domain model and the deciding the architectural separation of concerns? How do you allow for postponed, last responsible moment architectural decisions and reconcile that with optimal, loosely-coupled, high cohesive organization design? How do you organize for cross cutting concerns? What does an aspect-oriented organization look like? Technorati tag: Agile, David+Anderson, Lean