One of the most powerful tools for improving software development is to create more effective teams. Every method and every framework – Agile, Scrum, XP, waterfall, the various flavors of Kanban – depend on it. This short series of blog posts address the importance of effective teams for fully functioning lean software development. The series looks at:
This article is the second in the series and is a splitting up of an earlier blog Creating Teams in Scrum and Kanban to make the concepts more accessible.
The use of cross-functional teams is a powerful approach for eliminating waste in software development. As powerful as it is, it does not always make sense practically or financially. One of the critiques of classic Scrum is its naive insistence on cross-functional teams. And yet, even if cross-functional teams cannot be fully realized, there are approaches that offer some degree of the benefit. It just requires applying Lean ideas.
Like so much in the world, size and age impede flexibility! Development organizations / IT organizations larger than about 50 people require structures to manage the people aspect of development. Creating teams that cut across those structures requires significant managerial effort and trust, something that most of us resist. The age of software – how long it has been in development – can also make it hard to introduce cross-functional teams. Inevitably, there are people who have specialized skills in making the code work: subject matter experts (SMEs), architects, developers familiar with the old code, and other smart people who get called upon to support others. These people are in short supply. Putting these people on one cross-functional team would short-change other teams. Even if it were possible, it is probably not financially viable or advisable.
If it is not possible to use cross-functional teams, it is usually possible to create something that offers much of the benefit for a project. It may require thinking about “team” a bit differently and sacrifice some of the stability and commitment that fully cross-functional teams provides but it is attainable.
The key is to rethink what is a “team.” In our consulting practice, we go into organizations that already have many kinds of teams: development teams, test teams, business analyst teams, and so on. These are not the best sorts of teams for delivering value; instead, they are collections groups of people working on different things at any one time and handing-off work from team to team.
The better, more Lean approach is to form groups of people who are working together to build a particular vertical slice of functionality. Each group must contain the capability to analyze, design, code and test what is being built. At Net Objectives, we call these, “pods.”
In large organizations, it is often the case that one pod cannot by itself create and deliver all of the functionality needed to deliver the software product. For example, a pod working on a web frontend might have to depend on another pod that is building database or marketing functionality. To support this, we collect pods into “hubs.” A hub is focused on delivering value and is typically organized around an application or service. A hub will be comprised of those pods required to develop and deliver business value.
Pods offer a flexible way to realize the benefits of cross-functional teams at scale. Here are some approaches we have used:
Harness the power of cross-functional teams as much as you are able. If that is not possible or feasible, you can still get much of the benefit through the intentional and creative use of pods and hubs. This does not come automatically and is not part of classic Scrum or Kanban. But when it is done on purpose, there is great advantage.
CEO, Net Objectives
Net Objectives trains and consults in Lean-Agile, Scrum, Kanban for software engineering, and team technical practices. Let us know if we can help.
 Kanban is a widely used method for process management, software development, and transition management. The “Kanban Method” is one flavor of Kanban that is promoted by the Lean Kanban University company.
 We chose to coin the new terms, “pod” and “hub” rather than to add on yet more modifiers to “team” because “team” is overloaded with too many meanings and expectations.