Organizing for Agility

Agile practices can work in just about any organizational structure. The more you do agile, the more you'll identify areas in which you could optimize your organization to be more effective.

Let's first talk about functional organizations vs. cross functional organizations. In a functional organization, you have one group do product management, another do development, another for QA, etc. This made sense in waterfall because you handed off from one functional area to another.

In agile, it can work, but its success will depend on the relationships between the groups. If the relationships are good, it can work well. If they're bad and as a result people act defensively and create walls, then it won't go as well. Over time, you might move more towards a team with cross functional representation. Then there's no issue of competing agendas. It is all about making the team successful.

A couple of common exceptions. It can make sense to keep product management as a separate group. This will help in creating a common vision / direction. The product manager can become a virtual member of the team and be the product owner. Or a proxy can be created on the team who works closely with the product manager and plays the product owner role. It also might make sense to have some QA in a separate group. Say focused on a holistic regression suite (including scalability, etc.). They would then work with the QA members of the agile team who are focused on verifying the scope of the iteration for that team. If you break it out this way, you want to ensure that the feedback loop is as early as possible (don't wait until the end of the release; give feedback every iteration).

Who should be the scrum master of the team? I've had success where the manager of the team was the scrum master. This ensured that there weren't competing agendas: people will be judged on the success of the team. It also helps in that it gives the manager a lot of insights into what is going on (which helps with the people management part of their job). If the manager has multiple scrum teams, then whoever is in charge of the sub-team would be a good candidate for scrum master.

Other teams have gone the route where the scrum master isn't somebody with managerial responsibilities. This can work too. If so, you need to ensure that the communication between the scrum master and manager is good so that there aren't competing agendas / the manager gets a good feel for the dynamics of the team. Some teams even go so far as to rotate the scrum master role amongst the team. The concern here is that the role takes practice, so you'll potentially have a bunch of novice to good scrum masters instead of one good to excellent one.

The final aspect I want to touch base on is how to organize when you have multiple teams. Many large organizations organize by component. Agile can work in this structure. But it isn't ideal.

In many cases multiple components have to be involved in order to produce customer value. This adds a lot of complexity (coordination, timing, different priorities, etc.). If you were to organize your teams so that each team had expertise on each of the components, your complexity goes down a lot. Now the team can complete a story by itself.

Additionally, component teams tend to result in local optimization. Each component team is working on the most important things for that component. But if you were to take a step back, you'd realize that some of those things aren't important in the bigger picture. Cross component teams facilitate cross training and encourage a big picture view of priorities. They enable you to take on more work at the top of the priority list.

For a really good discussion of functional teams, check out Craig Larman's new book referenced here.