Self-organizing Scrum and agile teams need to determine how best to manage the flow of their work to get the job done each iteration. Flexible and high-performing agile development teams are composed of members with T-shaped skills and a Musketeer attitude that enable them to swarm to success.
Author: Kenny Rubin, Managing Principal, Innolution LLC, http://www.innolution.com/
Agile development teams are cross-functionally diverse and sufficient. They are comprised of team members that collectively have the skills to get the job done every iteration. Many organizations that apply agile are still trapped in traditional role-based thinking where every person is a specialist in his or her area. Having people with deep technical skills on teams is important. However, if everyone were a deep vertical specialist the team would be less flexible and more likely to encounter a blocking issue (e.g., too much work for the one specialist to handle) that prevents it from achieving its goals.
Agile teams should be composed of people with T-shaped skills (see the figure below).
T-shaped skills is a metaphor used to describe a person with deep vertical skills in a specialized area (such as database design) as well as broad but not necessarily very deep skills in other relevant areas (such as testing and documentation). For example, John is an expert Oracle DBA. This is his specialty and where be prefers to do work. However, John can also work outside of his core specialty area by doing some testing and documentation work. John doesn’t have deep skills in testing and documentation like people who specialize in testing and documentation do.
Teams comprised of people who have or are willing to acquire T-shaped skills tend to be more flexible and resilient in the presence of work bottlenecks because T-shaped skills enable swarming (more on this shortly). Not everyone on the development team must be capable of working on every task. That is a lofty goal to have, but not realistic in domains that tend to require intense specialization (like video game development). But, wouldn’t it be helpful if each team member could do some amount of work outside his or her specialty area? That way more than one person would be capable of doing each task (although perhaps not equally well or at the same speed).
In addition to T-shaped skills, members of the development team need to have the same attitude as the Three Musketeers: “All for one and one for all.” This Musketeer attitude reinforces the point that the team members collectively own the responsibility of getting the job done. They win as a team or they fail as a team.
Having team members with T-shaped skills encourages this attitude and makes it practical because people are capable of working on more than one type of task. On these teams a person who is capable of doing the work should never say, “That’s not my job.” However, because it is not always possible for a person to do every job, a team member might say, “I’m not capable of doing that job.” In this case the team might choose to have the person without the skills apprentice with a person who has the skills so that in the future the team will have greater aggregate capabilities.
Team members with T-shaped skills and a Musketeer attitude are in a good position to swarm. Swarming is a behavior whereby team members with available capacity and appropriate skills collectively work (swarm) on an item to finish what has already been started before moving ahead to begin work on new items. Swarming is part of an overall flow-management strategy that helps a team better meet the goal of getting the job done.
Teams with members that still think in terms of individual roles end up with some members far ahead and others who are mired in unfinished work. A classic individual-role-focused thought is “The testers might still have ‘their’ work to finish up, but I’m finished coding this feature, so I’m off to start coding the next one.” In a team that swarms, people would understand that it is typically better to stay focused and help get the testing done instead of running ahead to start working on new features.
While swarming favors working on fewer items concurrently, it doesn’t necessarily mean working on only one product backlog item at a time. One item at a time might be correct in a given context, but just saying that all team members should collectively focus on a single item at a time is potentially dangerous. A different number of items might be appropriate when considering the actual work that needs to be done, the skills of the team members, and other conditions that exist at the time a decision to start or not start working on another item needs to be made.
In summary then, when forming your agile teams, look to compose them with people who have T-shaped skills, a Musketeer attribute, and a willingness to swarm. Doing so will make your teams more flexible and successful.
About the Author:
Kenny Rubin is Managing Principal of Innolution, a company that provides Scrum and agile training and coaching to help companies develop products in an effective and economically sensible way. He is the author of the best-selling book Essential Scrum: A Practical Guide to the Most Popular Agile Process. He was also the first managing director of the worldwide Scrum Alliance.