Creating Teams When It Does Not Seem Possible

August 23, 2013 — Posted by Al Shalloway

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[1] – 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.

Introduction

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.

Get What You Can Get

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.”[2]

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:

  • A cross-functional pod. If it is possible to collect all of the skills needed to deliver value into one team and if these people belong only to that one team, then you have a pod that is, indeed, a cross-functional team. For all of the reasons already described, this is the most powerful structure to use. The team has all of the skills needed and they will work together long-term.
  • A pod with a core team and full-time extended members. In this case, the pod is consists a core group who are assigned for the life of the project. They bring in additional members as needed for the work at hand. For example, an application team requires some support from a component team. Traditionally, the component team would commit a certain percentage of their time to support the application team. This almost always leads to the two teams getting out of sync due to demands of other projects. Instead, it is better to create the pod with the core application team and to extend the pod with the appropriate number of component team members for the life of the project. The extended members attend the daily stand-ups of both the newly formed pod and also their component team. This way, the component team members can still identify with and stay connected to their component team. This is particularly useful when the component team uses different technology or skills than the core team.
  • A pod with a core team and part-time extended members. Sometimes, it is not necessary to have an extended member full-time. In this case, an extended pod member may be shared among two or three pods. More than that is not advisable: you want to ensure the extended member is available as needed.
  • A pod with a core team and a virtual extended team. Sometimes, the extended members truly cannot be on a particular pod. In this case, we advise setting up a Kanban board and managing their work load with work-in-progress (WIP) limits and explicit policies.
  • A virtual pod. If a pod cannot be created at all, then create a Kanban board that lays out the work to be done by the group of people and use Kanban to manage their workflow.

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.

Al Shalloway
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.




[1] 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.

[2] 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.

 

Subscribe to our blog Net Objectives Thoughts Blog

Share this:

About the author | Al Shalloway

Al Shalloway is the founder and CEO of Net Objectives. With over 40 years of experience, Alan is an industry thought leader in Lean, Kanban, product portfolio management, SAFe, Scrum and agile design.


Comments

Again, Al, great blog.

"You can't always get what you want
But if you try sometimes well you might find
You get what you need," Rolling Stones

Because I deal mostly with the biz/ops groups in companies projects no only include product development, but also activities like: marketing campaigns, budgeting, supply chain management, portfolio management and strategic planning.

As you stated, the ideal would be a dedicated project/program team from conception to discontinuation, but, as you said, most often no-can-do. Individuals involved in the lifecycle process can be asked at any moment about projects in development, products in the market, and a program about to be rolled out.

At least I've helped stakeholder understand that continuous, synchronous communication of any changes in their purview is critical to a program's success and a product's maximum ROI.

Mark:Thanks for the kind words and for your great ideas in your earlier comment.

Blog Authors

Al Shalloway
Business, Operations, Process, Sales, Agile Design and Patterns, Personal Development, Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Cory Foy
Change Management, Innovation Games, Team Agility, Transitioning to Agile
Guy Beaver
Business and Strategy Development, Executive Management, Management, Operations, DevOps, Planning/Estimation, Change Management, Lean Implementation, Transitioning to Agile, Lean-Agile, Lean, SAFe, Kanban, Scrum
Israel Gat
Business and Strategy Development, DevOps, Lean Implementation, Agile, Lean, Kanban, Scrum
Jim Trott
Business and Strategy Development, Analysis and Design Methods, Change Management, Knowledge Management, Lean Implementation, Team Agility, Transitioning to Agile, Workflow, Technical Writing, Certifications, Coaching, Mentoring, Online Training, Professional Development, Agile, Lean-Agile, SAFe, Kanban
Ken Pugh
Agile Design and Patterns, Software Design, Design Patterns, C++, C#, Java, Technical Writing, TDD, ATDD, Certifications, Coaching, Mentoring, Professional Development, Agile, Lean-Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Marc Danziger
Business and Strategy Development, Change Management, Team Agility, Online Communities, Promotional Initiatives, Sales and Marketing Collateral
Max Guernsey
Analysis and Design Methods, Planning/Estimation, Database Agility, Design Patterns, TDD, TDD Databases, ATDD, Lean-Agile, Scrum
Scott Bain
Analysis and Design Methods, Agile Design and Patterns, Software Design, Design Patterns, Technical Writing, TDD, Coaching, Mentoring, Online Training, Professional Development, Agile
Steve Thomas
Business and Strategy Development, Change Management, Lean Implementation, Team Agility, Transitioning to Agile
Tom Grant
Business and Strategy Development, Executive Management, Management, DevOps, Analyst, Analysis and Design Methods, Planning/Estimation, Innovation Games, Lean Implementation, Agile, Lean-Agile, Lean, Kanban