I wanted to post some collected thoughts on organizational structure for larger scale agile organizations. So here goes...

What do I mean by larger scale? Well typically most agile writing only addresses single teams, who are free to work on their own without interference and who single-task on a single project until completed. The main exception in the literature is Feature Driven Development where the method was created and designed for use on medium to large size projects or programs.

Optimal large agile organizations consist of small highly cohesive teams that are loosely coupled!

Ever find yourself in one meeting after another with a different set of people - where each time you are trying to agree who will work on what and how to avoid treading on each other's turf? Often these meetings seem to drag on for days, weeks or months and very little work gets done. It can degenerate in to turf wars or managerial squabbles about who owns what. A lack of cohesion across teams leads to a lack of momentum because people don't know what to do or who to work with or even if they do, the colleague is often on a different team and assigned to different work with a different priority. A lack of cohesion in the definition of roles and responsibilities produces a very large amount of waste.

We might define this type of waste as the amount of time we spend talking about working as opposed to the amount of time spent collaborating on real work. A good ratio might be 1:10, a typical one can be 1:1 and in some organizations it can be more like 10:1 in favor of waste.

All of this leads me to my main point. Architecture is important. A well defined loosely coupled, highly cohesive architecture enables an organizational structure that significantly reduces waste. It is precisely this idea that is enabled in FDD Feature Teams with the Chief Programmer acting as the interface between loosely coupled teams.

Although coupling and cohesion predate object-oriented, aspect-oriented and service-oriented architectures, they ideas still hold. The idea of a cohesive class, component, aspect or service still holds. What is encapsulated inside the class, component, aspect, or service ought to be cohesive and through its interface (its method signature) it ought to be loosely coupled. The same is true for organizations. Encapsulation, the idea that an org can work on stuff without outside interference is amazingly liberating and powerful. We have a word for it - Empowerment.

Architecture and analysis are vital to scaling Agile/Lean concepts across larger organizations. Without a loosely coupled, highly cohesive architecture on which to map the organizational structure, it is impossible to minimize the waste from communication overhead. You can't refactor organizations in the way you can refactor code. Emotional intelligence is involved and there is a lot of emerging evidence to suggest that the older emotional part of our brain doesn't process and re-wire as quickly as our logical processing centers. How often have you seen an employee complain about organizational change? As a member of my staff once told me, "You're the fifth manager I've had in 15 months and I can't stand it!"

We live with these challenges every day in Visual Studio Team System. Around 450 people work on the product. There are six product units with up to 150 people in each one - some are significantly smaller. The Team Foundation Server product unit is split across two geographic locations and organizing the groups in Redmond and Raleigh as cohesive, loosely coupled units has taken some time and effort on the part of the management. Much of the talking we do is about who owns what, how the architecture maps to the organizational structure and as our picture of the product and its function clarifies where each piece of work should land - determining who is responsible for the work and what are the dependencies between teams. Minimizing dependencies and coupling between teams and product units and creating clear lines of communication through loosely coupled interfaces - known as Program Managers at Microsoft - is part of daily life on a large scale software project. Watch for part 2 tomorrow... Technorati tag: Agile, David+Anderson, Lean, FDD