- About Environment, Products, Size, and People
- Consider Specialization First...
- ...And Generalization Second
- Widen People's Job Titles
- Cultivate Informal Leadership
- Watch Team Boundaries
- The Optimal Team Size Is 5 (Maybe)
- Functional Teams versus Cross-Functional Teams
- Two Design Principles
- Choose Your Organizational Style
- Turn Each Team into a Little Value Unit
- Move Stuff out to Separate Teams
- Move Stuff up to Separate Layers
- How Many Managers Does It Take to Change an Organization?
- Create a Hybrid Organization
- The Anarchy Is Dead, Long Live the Panarchy
- Have No Secrets
- Make Everything Visible
- Connect People
- Aim for Adaptability
- Summary
- Reflection and Action
This chapter is from the book
This chapter is from the book
This chapter is from the book
Move Stuff out to Separate Teams
The nice thing about not being directly involved with any method, framework, alliance, or consortium, is that I can be a heretic and say anything I want. The worst thing that can happen to me is that I'm being flamed and grilled when I'm on a conference panel. That is why I have fire-resistant gel in my hair. But I've noticed there's a market for contrary ideas. And as a firm believer in markets, I love exploiting opportunities of dissent whenever I can. Like in this case.
I believe it is sometimes better to move specialist work to (functional) specialist teams. This could be necessary for project management, architectural components, user interface design, hardware design, testing, or any other work that deviates significantly from standard activities in a project team. This goes against "accepted" thinking in the Agile community because many strong voices suggest that all work, from story to binary, should better be done by cross-functional project teams, including coordination of efforts across multiple teams. The Scrum of Scrums is a good example. It says that each team sends a person to a daily Scrum of Scrums meeting, and these people then coordinate the work across the teams. Such suggestions have been made for Scrum Masters, technical leads, user interface designers, and lead testers.
But I believe it is simply a matter of balancing communication. If it turns out that user interface designers need each other more often than they need the team members working on delivering business value to customers, then it is right for them to sit together and form their own team. Likewise, project dynamics in a company may be so intense or complex that project leads of different teams require intense collaboration. Then it might be better for them to get together and form their own team. Perhaps even a Project Management Office.
BUT...five things are important here:
- First, when some responsibility, like project management, architecture, or GUI design, is moved outside the project teams, every (cross-functional) project team needs a communication interface to the (functional) team that is formed around the specialist activity [Leffingwell 2007:108]. One can think of regular attendance of the specialists in the project teams' stand-up meetings and/or some designated representative from the project teams in the specialist team. Plenty of options are available and should be applied to address the issue of the bandwidth of communication between the project teams and the specialist team.
- Second, the people who are moved into a specialist team must see themselves as value units, just like system administrators are servicing project teams, not controlling them. Specialist teams should consider project teams to be their "customers," not their subordinates, and organize their processes accordingly. They sell their services to their colleagues in the other teams, just like I'm trying to sell my dissenting views to you. (I'm glad you invested in this book before you got this far.)
- Third, the project teams should decide whether the specialist team is actually delivering any value. Such a market approach would counterbalance the tendency for support units to suboptimize at their own level. For example, in my last position I could choose to go to our unit of expert interaction designers, or I could choose to do interaction design myself. It all depended on how well (and how soon) our interaction design unit was able to service me and my project. (And note: I have developed some skills in dissent and design.)
- Fourth, we know that the total amount of communication in a complex system remains (more or less) the same, no matter how the system reorganizes itself. Therefore the teams and their managers will figure out how many points of contact with other teams they can handle. Both too little and too much is bad for the adaptability of the organization.
- Fifth, a team of specialists can be virtual instead of physical. It can be just a matter of getting all user interaction designers together once in a while, and allowing them to agree on common standards and approaches across the cross-functional teams where they actually do their work. Such virtual teams are called communities of practice, and they are a good compromise, bridging the need for cross-functional teams and the need for coordination among specialists [Augustine 2005:71–73] [Larman, Vodde 2009:252/253]. (Note: Some organizations have centers of excellence with a similar purpose; although these COE tend to be a bit more formal in nature.)
It is possible, and perhaps even preferred, that the formation of specialist teams is a result of self-organization. Specialist teams form themselves organically in an attempt to solve a problem that is shared across multiple teams. For example, a continuous integration (CI) team forms itself as a spin-off in an attempt to provide a more professional CI service to the other teams. Team members from the various project teams then have a choice of full-time, part-time, and/or rotating membership [Highsmith 2009:272/280]. Another example is that of a component team, which designs, builds, and delivers an architectural part of a solution to the project teams, whereas the project teams together act as customers to the component team [Cohn 2009:185]. The primary reason for the formation of specialist teams is efficiency and effectiveness (productivity through division of labor).
We can even imagine that these specialist units grow and form their own little hierarchies. They may even have a number of rules that apply to project teams if these teams decide to make use of their services. But like in any market environment, the specialist teams (and their rules and hierarchies) can and should be dissolved as soon as the need for them evaporates.
In each of these examples it is clear that the project teams are consuming and the specialist teams are providing (see Figure 13.8). And so it should be the same with a project management office (PMO), if it exists. A PMO is in the business of servicing project teams in getting projects organized. Project managers, like user interface designers, architects, and system administrators, are not line managers. And nobody should ever be expected to "report to" the PMO. Instead, the PMO should respectfully ask the teams for information and deliver something that the teams and their customers can actually use.
)
Figure 13.8 Project teams serviced by specialist teams.