Organizational Issues

It seems like large companies have evolved to adopt some practices which, in retrospect, are not ideal. Some common ones: specialization, multi-tasking and not refactoring. In this blog entry, I'll cover specialization. I'll cover multi-tasking and not refactoring in future entries.

The theory with specialization is that if you have people specialize then they will get really good at that area and do the best possible job. If you put similar people together in a group, they'll feed off each other and you'll end up with consistent best practices for that specialty within the organization.

Here's where it breaks down. Each of these functional areas in itself does not add value. They must work together to get things done.

In a waterfall process, this was typically done through documentation. Each functional area would do its part and create a document as input into the next functional area. Documents are not a very efficient way to communicate. You have to make all sorts of assumptions on what the reader will need and their perspective. Conversation is much more efficient as you can quickly tailor it to the need of the audience. Working on things together (collaborating) ensures that you won't go too far down a wrong path.

Another issue with functional teams (or component teams for that matter) is that each team typically has a different manager and thus different priorities (and the ensuing complexity of trying to reconcile them). You want to create a cross functional team that has the same priorities (the backlog is a way to drive reconciliation). In other words, a team that can get the work done end to end by itself. This reduces complexity tremendously.

A third issue is that of staffing. How much do you put in each area? That depends on what you're going to focus on. And these priorities change over time. So even if you have a good allocation now, you'll likely have a poor one in the future. So what you need is the ability to shift resources to best meet the priorities. In other words: generalization. The ability to help out in other areas.

Many companies switch back and forth between centralized and distributed models (like a pendulum). Agile practices encourage the distributed model (where the specialists are in the cross-functional team). You can then promote community within those specialties so that things that need to be coordinated can be. As an intermediate step, you can leave the organization as is and have virtual teams (where people dotted line in). The key here is that the delivery team needs to be the priority as it is the one that is actually creating the primary business value.

What about functional areas that aren't needed in enough numbers to be in each team? Some examples include product managers, architects, usability and maybe writers. For these, you can potentially add them in at the next level up (scrum of scrums). For example a product manager might be product owner for two or three teams. Your goal is to keep them to as few teams as possible (i.e., better to play the full role on two projects than half of the role on four projects). More on this in the next blog entry on multi-tasking.