- Feed Them Two Pizzas
- Favor Feature Teams
- Self-Organizing Doesn't Mean Randomly Assembled
- Put People on One Project
- Guidelines for Good Team Structure
- Onward
- Additional Reading
This chapter is from the book
This chapter is from the book
This chapter is from the book
Self-Organizing Doesn't Mean Randomly Assembled
The ability for a team to self-organize around the goals it has been given is fundamental to all agile methodologies, including Scrum. In fact, the Agile Manifesto includes self-organizing teams as a key principle, saying that "the best architectures, requirements, and designs emerge from self-organizing teams" (Beck et al. 2007). As part of deciding how best to achieve the goal given them, some teams will decide that all key technical decisions will be made by one person on the team. Other teams will decide to split the responsibility for technical decisions along technical boundaries: Our database expert makes database decisions, and our most experienced C# programmer makes C# decisions. Still other teams may decide that whoever is working on the feature makes the decision but has the responsibility of sharing the results of the decision with the team.
There are two key points here: First, not every team will choose to organize themselves the same way, and that's OK. Second, making use of the collective wisdom of the team will generally lead to a better way of organizing around the work than will relying solely on the wisdom of one personnel manager. However, the benefit of allowing a team to self-organize isn't that the team finds some optimal organization for their work that a manager may have missed. Rather, it is that by allowing the team to self-organize, they are encouraged to fully own the problem.
A common criticism of self-organizing teams is, "We cannot just put eight random individuals together, tell them to self-organize, and expect anything good to result." Well, I don't know if that's true, but when we are putting together a two-pizza Scrum team, we are definitely not doing so with eight randomly selected individuals. In fact, those in the organization responsible for initiating a Scrum project should expend a lot of effort in selecting the individuals who will comprise the team.
In the original paper describing Scrum, Takeuchi and Nonaka identified "subtle control" as one of its six principles. They list staffing decisions as a key management responsibility.
- Selecting the right people for the project team while monitoring shifts in group dynamics and adding or dropping members when necessary [is a key management responsibility]. "We would add an older and more conservative member to the team should the balance shift too much toward radicalism," said a Honda executive. "We carefully pick the project members after long deliberation. We analyze the different personalities to see if they would get along." (1986, 144)
Getting the Right People on the Team
If you are a personnel manager or otherwise influence team composition in your organization, some of the factors to consider are the following:
- Include all needed disciplines. As a cross-functional team, it is important that all skills necessary to go from idea to implemented feature be represented on the team. Initially this may mean that team size is slightly larger than desired. But, over time, individuals on a Scrum team will learn some of the skills possessed by their coworkers. This is a natural result of being on a Scrum team. As some team members develop broader skills, other individuals can be moved onto other teams.
- Balance technical skill levels. Subject to considerations of team size, you should strive to balance skill levels on the team. If a team has three senior programmers and no less-experienced programmers, the senior programmers will need to code some low-criticality features that they could find boring. Not only might a junior programmer have found such features enjoyable to work on, that programmer would also benefit from learning through association with the senior programmers.
- Balance domain knowledge. Just as we strive to balance technical skills, we should strive for a balance between those with deep knowledge of the domain in which we are working or the problem we are attempting to solve. This is not to say that if we have the opportunity to assemble a team entirely of domain experts we shouldn't take it. Rather, we should consider the long-term goals of our organization. One of those goals is likely the build up of domain knowledge throughout the organization. You'll have a hard time achieving that if you put all of the domain experts on one team.
- Seek diversity. Diversity can mean many different things—gender, race, and culture being just three among them. Perhaps equally important can be how individuals think about problems, how they make decisions, how much information they need before making a decision, and so on. Homogeneous teams reach consensus more quickly than do heterogeneous team, but they do so by failing to consider all options (Mello and Ruckes 2006).
- Consider persistence. It takes time for team members to learn to work well together. Strive, therefore, to keep team members together who have worked well together in the past. When forming a new team, consider how long members will be able to work together before some or all are dispersed to other commitments.
If possible, take the dominating personality aside and inform her of the issue. Let her know that even in situations where she may know the "right" thing to do, she should sometimes refrain from voicing her opinion before others have a chance to express their thoughts. Ask her if she thinks the team would make the right decision if she were to present her thoughts as an opinion rather than as an unchallengeable decision. Enlist her assistance as a mentor to the others—her job should be not just making sure the right decisions are made but that team members grow such that they will make the right decisions on their next projects, where she may not be there for them.
If they look to you, look back right at them. If you are the team's ScrumMaster, make sure they know that your job is to support them, not to make decisions for them. If you are a team member, you do not need to subjugate your opinions and keep quiet all the time. However, you should look for ways to engage others by not making the decision in all cases. For example, try asking questions of others before giving your opinion.
If they have enough experience to build a software product, they probably have enough experience to figure out how to organize themselves. If not, provide them with training or coaching. Often, this objection really masks the objection of, "I don't trust the team to self-organize in the way I want them to." Too bad. Exert subtle control over the team in who you put together to form the team and the goal you give that team, not in how it does its day-to-day work.