Cross Team Agile Header
Cross Team Agile Header

Cross-Team Initiatives in an Agile World

5 min read

Recently, I spoke with a client about a struggle I’ve heard from others: how can a company adhering to an agile work methodology best implement company-wide initiatives which affect the very fabric of its organization?

Something like implementation of GDPR (General Data Protection Regulation) policy influences the day-to-day of all levels and departments of a company, from sales to HR and controlling to marketing—no one is exempt. Still, how do project managers in an embedded agile environment implement these changes after having shifted to a client-focused structure free of centralized PMOs?

Trend: Projects to Products

With such widespread adoption of the agile working method, particularly in the IT sector, the focus is changing. A new trend is emerging worldwide: companies do not necessarily focus on organizing work in an agile fashion at the project-level, but rather on making the entire organization more agile.

The “old” model, where project managers fought over resources and negotiated priorities, is growing antiquated. Instead, organizations are thinking long-term. Gone are the days of lengthy negotiations about individual projects, complaints about project delays, the painstaking process of assembling a team for each new project, thumb-twiddling until the right experts are available, and subsequent disputes over change requests.

The focus has shifted to “products” or “value streams” — long-term investments. Teams are now multidisciplinary entities working together regularly. In other words, they are cross-functional teams who can function with greater independence from other organizational units.

I won’t go into more details about these approaches in this post, though other approaches such as on SAFe, Large-Scale Scrum (LeSS), Nexus or Flight Level (FLM) do make for good reading. Still, there are many opposing viewpoints on these approaches, even within the agile community, interestingly even amongst the authors of the original Agile Manifesto.

Products No Longer Require Resource Management

What I’m concerned with is the question of whether you still need resource management when your teams are fixed and permanent. With a team comprised of subject matter experts, technical specialists, and managers working together regularly, the traditional issues of resource management are reversed: projects no longer wait for resources, now resources wait for projects. Teams work through a topic to pull the next one from the prioritized backlog.

Interestingly, our customers no longer speak of “projects,” but rather “business epics,” “features,” “insurance products,” or “customer offerings” — precisely the terms that internal departments have always used.

To summarize these developments:
  • Rise of dedicated teams
  • Technical and subject matter experts work together directly
  • Prioritized backlog instead of project portfolio management
  • Multi-level prioritization (at the bottom for the sprint, from above for the product, from above for a program or release train, etc.)
Cross Team Goodbye Resource Management

So Long Resource Management… or?

And so, we close the book on resource management and bid a lukewarm farewell to an old frenemy and all those years of resource requests, soft and hard bookings, short-term interventions, and comparisons of planned and actual figures.

However, as you may have guessed from the subheading, the need for resource management persists even in 100% agile organizations.

Management of short-, medium-, and long-term personnel requirements remain, such as:

  • Team composition, including decisions on capacity and necessary skills
  • Managing team capacity development
  • Managing skill composition and development within the team
  • Short-term planning of absences to realistically determine sprint capacity

Furthermore, and here is where it gets interesting, there are situations where resources need to be shared across teams even in optimally structured organizations. This tends to arise due to:

Scarcity

Some skills are in such high demand and supply is so scant that they cannot be dedicated to a single team. So, they’re still bottleneck resources that teams need to organize around and consider their availability in their own planning.

Project-related necessities

The need for company- or department-wide initiatives (e.g., GDPR integration mentioned previously) requires the involvement of many individuals and must be coordinated across departments to achieve the project goal by a specific deadline.

Managing in an “Un-Agile” Environment

Regarding the scarcity issue, two “traditional” methods for managing bottleneck resources in an agile manner already exist. Either the requirements of different teams are collected and prioritized in a separate backlog, or teams are provided with capacity quotas. Teams must then include time dependencies in their own sprint planning.

The second issue, coordination of cross-departmental initiatives, can be tackled through two different approaches:

Deconstruction and distribution
Cross Team Deconstruction and distribution

Deconstruction means breaking down a cross-departmental project in such a way that individual work packages/features/epics can be handled by different teams. Project management of this cross-departmental initiative is then responsible for orchestrating the implementation across relevant teams. At the same time, the product owners of the individual teams are instructed to prioritize the corresponding work packages. In this way, special “non-value stream” work packages are implemented in the teams.

Dedicated capacity
Cross Team Dedicated Capacity

Instead of distributing the work among teams, capacity is decoupled from them, meaning that individuals are partially or completely removed from their teams to form a “classic” project team. Project management can then more easily control the sequencing of activities and reduce buffers and waiting times.

A Comparison of the Two Approaches

Deconstruction and distribution is generally preferred when:

  • Work packages can be decoupled easily
  • Project size is manageable such that project management can easily monitor work across multiple teams
  • The project is not highly time-sensitive

On the other hand, dedicated capacities are generally preferred when:

  • The deconstruction of work packages would be too complex
  • There are many interdependencies
  • The project is time-sensitive or has a fixed deadline
  • Political factors favor the formation of a tightly knit team

In Both Cases: It’s All about the Overview

Whether you divide work into a team or put together a temporary team, the following factors will always be crucial for success:

  1. Clear objectives and motivated project management, as always
  2. Unequivocal support and prioritization from upper management, political support – otherwise, the teams won’t be on board
  3. A clear overview of dependencies. You need to keep track of which activities depend on other resources and which activities need to be prioritized to deliver to other projects or teams on time
Cross Team Milestones and Dependencies

Illustrative depiction of dependencies between different projects

How far along are you in your own agile transformation? How do you handle on company-wide initiatives? Stories in your teams? Dedicated capacity and scarce resources? Whether A or B (or even C!), we wish you success in all your upcoming projects/undertakings/business epics/features/big points… 😉 and are eager, as always, for your feedback.

close
Your battery is almost empty.