Balancing Generalists and Specialists– Building Successful Agile Teams

It cannot come as a surprise for anyone that agility encourages team members to do "stuff" outside of their skill base. To have a willingness to do work they are neither familiar with nor even have all the right skills. Agile teams balance size and skills to ensure they can deliver value. Are agile teams always perfect in doing this? No, and actually they should not be. Team structure is a complex problem and there is no perfect answer. But like everything with agility, the best way to solve the problem is to "do something" and then review it - inspect and adapt through transparency. But that simple idea does not always help you when looking at team composition. So, let’s talk through some scenarios.

What about work that requires deep technical skills?

Imagine I am building an MRI product that requires deep physics knowledge. Would we place physicists on the Scrum Team? The answer is, it depends :). If the work requires lots of "physics" stuff, then it would make sense to include that scientist in the team. If the work requires a significant amount of contribution by the physicist and there are numerous dependencies of that work with others on the team, then the cost of delay, opportunity for miscommunication and general synergies of having that person on the team outweighs any issues of departmental boundaries or cost. If, however, the work is not focused on the physics "stuff" and instead more focused on the implementation of those ideas then it is possible the physicist would not be on the team helping out when necessary. In fact, the physicist would not just be helping out but also looking for learning opportunities where they could make their teammates better team members by helping them learn more physics when delivering value. The key choice that the team makes in composition should not be based on traditional departmental boundaries but instead be focused on the work. If the work is totally unknown, then just get going with what you have and see what happens. You will learn quickly who should or shouldn’t be on the team.  

The bottom line is that in an ideal world if a team needs deep technical skills, then those skills need to be on the team. If they are not then those skills will create a large number of dependencies, which ultimately will undermine the team’s ability to deliver value.

What about situations when we do not have enough skills to go around?

Scrum is not magic and will not solve this problem. If you do not have enough skills to do the work or do a great job in the work, then it will not magically create those skills. What it will do is make that problem very evident in the Increment (stuff that is delivered), the Sprint Review, the Retrospective, Sprint Planning and the Daily Scrum. Actually, it will be evident in all of the Scrum events. Scrum might not be magic, but it does make problems very evident, encouraging the team to solve them. Skills are one set of challenges that teams face and Scrum will make them, or the lack of them very apparent to everyone. This will, however mean choices need to be made by the team and the management of the environment the team works within. There is no blaming the system with Scrum.

Many teams doing Scrum describe the sensation of being on a Scrum Team like being in a startup. It is rare that a startup has all the right skills to deliver the best product, but they have enough to do something and will beg, borrow and steal the knowledge and experience to fill in the gaps. How many times have you visited a friend who works in a startup to find the next two hours are filled with questions and review opportunities? They might buy you a beer or two, or invite you for dinner, but ultimately, they are filling in the gaps of their teams. You will never build a perfect team and that is very true in a startup, but also true in an enterprise setting. The more complex the problem the less likely the team will be perfect on day one. But the great thing about Scrum is that you have many opportunities to learn, change and improve. There is a false belief in traditional project management approaches that it is possible to not only plan all of the work up front, but also determine who should be involved and what skills you need. Scrum accepts the reality of not knowing with the idea that you plan enough to get going in terms of the work and the team composition.

But doesn’t it mean that people are sitting around

Many people worry that when you load your team with all the skills necessary to deliver the work that team members might be sitting around waiting. After all, the work distribution is never smooth, but actually always a bit lumpy. For example, programmers are waiting for specifications, testers for a product to test, and deployment experts can’t do anything until they have something to deploy. The reality is that Scrum does not create the most efficient system for people based on their existing skills. That means that people will have to help with work that is outside of their comfort zone, or their previous experience. Ideally, they will be working with people who have done the work before and can share that experience with them. This "messy-ness" can be quite off putting for traditional project managers who want to optimize the work through "resources" ensuring their "utilization" is maximized. Scrum "utilizes" the team by encouraging transparency, allowing frequent planning of the work, and who does it.

In practical terms that means a team is looking to storm by getting people to work together on tasks and always has an eye on what is next in the Sprint to ensure that everyone is being effective as possible. The team is also looking at their skills, ensuring that they are spreading knowledge throughout. This in particular is very different from traditional industrial approaches that encourage knowledge and skill hording to create scarcity and a heavy dependency on one person.

My what about job titles?

For many the lack of detailed job titles within Scrum can be confusing. We hire a job title, we reward a job title, we promote people to a job title. The industrial model of work requires detailed description of jobs which then is grouped into a job title, which is then compensated and part of a career path. The agile approach is different. It does not describe detailed job titles based on the tasks performed because complex work means the team does not actually know, in detail the tasks that will be performed. Instead Scrum builds some flexibility into the team structure to support complex work. A Scrum Team is built around three roles: The Product Owner, who describes the order, priority and value of the work; The Scrum Master who ensures that Scrum is being followed which means an empirical process, self-organization and continual improvement; the Development Team Members which are the group of people who actually do the work and deliver the value. Anyone can be a Development Team Member and who is required will depend on the work. Job titles provide a great clue for deciding who is in the team, but should not determine what, when in the team the people should do. The key idea is that team members are flexible.

Of course, individuals still need a career path and building deep skills is important. But it must be balanced with a community based, knowledge sharing culture. Individuals will prosper not because they are a bottleneck with unique skills, but from their ability to help others and develop the skills of the whole community.

Does that mean that teams can change?

A myth about Scrum is that the Scrum Team never changes. Yes, change comes with a cost. The cost of new people learning to be part of the team. But that cost needs to be balanced with the ultimate cost of not having the right people on the team. Also, it is important that the teams and the team members choose where they work, and you do not rely on some magical resource planning group to find the right people to solve your problem. Communities of practice might be a great tool for supporting the changing needs of the Scrum Teams with practice leaders not only providing mentorship and development but also help teams that need different skills or people. Just like the rest of agility, people allocation, also known as resource management, is pushed down to the people who are closest to it - the teams, and teams of teams deliver value.

So, there is no magic system for building perfect teams?

I remember the holy grail of resource management where work was routed based on skills and availability and the worker could pick up the work and based on the process, do it without any real knowledge of the whole process or the final outcome - the ultimate industrial process for knowledge work. But the reality is the more complex the work, the harder it is to build the right team up front. And the idea that rather than build a real team, the work can be conducted through different specialists by a Project Manager not only requires the work to have nice boundaries, but also ignores the fundamental benefit of different "diverse" people working together to create something unique and special. Focus on a team of highly motivated generalists that can beg or borrow the knowledge to get the value delivered. And then inspect that team, the work, and the skills they need and adapt when you realize that we are missing something.

About the Author

Dave West is the Product Owner and CEO at Scrum.org. He is a frequent keynote speaker and is a widely published author of articles and co-author of two books, ‘The Nexus Framework For Scaling Scrum’ and ‘Head First Object-Oriented Analysis and Design’. Twitter @davidjwest