4

We have a set of teams and they are trying to go Agile. Lets say each team support one application and we have a total of 4 teams and 4 applications. When we projects that are all within a team / application and the backlog fits within the team, everything seems to work fine. Where it gets tricky is if there is a backlog where:

  1. Some projects are fully scoped within a current team / application
  2. Other projects are cross team /application initiatives that are taking place which includes other folks outside the team included in #1.

It seems like there are two agile recommendations that seems conflicting:

  1. The desire to create feature teams (which would span folks across the app teams - presumably taking a few folks from each app team) so every "project team" has a single ability to deliver the whole feature by themselves

  2. The desire to have long lived teams that can increase trust, good history of tracking velocity and better estimation.

The problem with this first approach (and why it conflicts with the second) is you keep creating new project teams to map onto the project scope and teams form and dissolve over and over again so you don't get the long lived velocity tracking, of those cross functional teams.

Is there any advice to this seemingly contradicting ideas?

  • 1
    Not sure this is an answerable question. I disagree that it is a contradiction - at least from my experience. You're going to need to go into more specifics about why you can't have general purpose teams that could deliver more than one specific project. This is what agile teams do; why are you special? I'm not saying you aren't, but it is very rare. – Dave Hillier Nov 17 '13 at 20:16
  • my point is how to manage cross functional projects that bring together what was previously considered multiple teams – leora Nov 17 '13 at 20:24
  • 1
    Yes, merge into project teams, then keep them as long lived teams. That is it, then you're finished. Deliver projects. If you want more specific help then you need to be more specific; what industry are you in what disciplines are you merging? – Dave Hillier Nov 17 '13 at 20:25
  • lets say we own a portfolio of 3 applications. Normally these result in 3 different backlogs and each of these apps are independent. now suddenly there is a feature that spans all 3 teams. If some folks from each of those teams form one cross app team for this larger project then if there is no other cross app projects that team by definition will NOT be long lived . . I don't think my questions has anything to do with industry specifics but i will update my question to be more explicit – leora Nov 17 '13 at 20:34
  • I updated the questions to hopefully be more explicit – leora Nov 17 '13 at 20:36
2

TL;DR

Don't create a false dichotomy by confusing the organizational choice of how to structure teams with the mechanism for scaling the Scrum framework up within the enterprise. The team structure you choose will impact your level of integration effort, but does not ultimately affect the scaling mechanism itself.

Regardless of how you form your teams, each team will work from a single Product Backlog for a given project. However, the enterprise can also have a Product Backlog, and delegate sub-projects to different teams in order to operate at scale.

A Project Has Exactly One Product Backlog

By definition, each project has exactly one Product Backlog. Likewise, each team works from exactly one Product Backlog per Sprint.

What you're describing sounds like a situation where you may want more than one team to work from a single over-arching Product Backlog managed at the enterprise level. There are a number of ways to solve the problems involved in scaling Scrum for the enterprise, including:

Most of the complexity comes from the fact that your organization is not currently aligned with the way your projects are staffed and work is distributed. This is largely a process-engineering issue, although you may find that some changes need to be made to your organizational charts, too.

Two Short Examples

If you have a new product that will span multiple teams across the enterprise, you already know your organizational choices:

  • Teams formed to deliver a specific feature or project.
  • Teams formed as cross-functional units, to which features or products are delegated.

There are organizational pros and cons to each approach, but that is outside the scope of the original question. Let's look at two examples of how the project might be scaled.

Feature/Project Teams

The enterprise backlog is formed, and themes and epics are carved out to define the sub-projects that you will form Scrum teams to deliver. Each team is given a single Product Backlog that is composed of the themes and epics that define the team's objectives.

The Product Owner and the Scrum Master for each Scrum team then participate in the Scrum-of-Scrums (or your scaling framework of choice) where the enterprise-level Product Backlog is coordinated.

Because the team is often feature-focused, there is often more coordination required at the Scrum-of-Scrums level, and lot more inter-team dependencies will need to be managed at all levels. However, the team's narrow focus may make it possible to work with teams that are less cross-functional, because the cross-functionality exists between teams rather than inside each individual team. This is one of the many trade-offs you must make at the enterprise level when you plan the top-level project.

Cross-Functional Teams

This is actually very close to the previous example, except that the teams aren't formed around specific features. Instead, the team's Product Backlog is composed of vertical slices that leverage the cross-functional nature of the team to deliver functionality to the Scrum-of-Scrums.

This approach reduces interdependency between Scrum teams within each Sprint, but still requires active coordination at the enterprise level to ensure the work integrates at the end of each iteration. In addition, by ensuring the teams are fully cross-functional rather than specialized, there is more flexibility to move enterprise-level Product Backlog items between teams as capacity, requirements, or priorities change.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.