How Agile By Design scaled the growth of the GPG agile team

The challenge

As covered in our initial case study for Scotiabank, Agile By Design introduced new agile principles and methods to the Global Payments Group (GPG) that started a transformation from a once disjointed and disengaged organization into a more efficient and effective team-based model.  

The GPG project team embraced its newfound autonomy and results-driven ethic, and the size of the team grew quickly to include the necessary expertise. The team began to separate organically into smaller groups to deliver different features. But as it expanded, the size of the team became unwieldy.

Official sessions were long and started to feel bureaucratic.  The Kanban became hard to navigate. Some people were multitasking too much; product owners and scrum masters were especially stretched. Work would temporarily get lost in the shuffle.

In short, we were victims of our own success. 

But amid the churn and confusion, there was the kernel of a great idea.

The approach

The team wanted to maintain the common identity they now felt and their many synergies: common platforms, the same customers, shared stakeholders, and a common purpose. But it needed more structure to continue to be effective.

We started by dividing the team into three separate but closely associated pods. Each pod would be responsible for the detailed analysis, development, and testing of small numbers of features over time.

Team members would work primarily in their pods. When dependencies were identified, people would pair across pods. There was a common planning and demo cadence as well as a weekly stand-up. In the team Kanban, we created swim lanes for the separate pods, which eventually became separate Kanbans within the common payments group Kanban.

The payments group team had become an Agile ecosystem.

An Agile ecosystem can evolve organically, accidentally, or intentionally. It is composed of a small number of market-facing teams, along with dedicated resources allocated to support those teams. External stakeholders and even market actors can be considered part of an Agile ecosystem.

By being intentional in identifying our ecosystems, we could contain cross-team dependencies. In an enterprise setting, containing dependencies to a smaller social circle (e.g., the ecosystem) is often more tenable than getting to truly independent teams. 

The Onion Eco-system

An ecosystem must be composed of a limited number of people. Research sociologist Robin Dunbar in the 1990s suggests that there is a finite number of others—roughly 150—with whom a person can have meaningful relationships. Beyond that number, true collaboration becomes impossible. 

Dunbar’s Number help us set up organizational context boundaries. A context boundary is a boundary we can place around a group of people that shares a particular context, a common outcome, a shared platform, or the same problem or solution space. Larger context boundaries contain smaller context boundaries--contexts can and do nest, like in the “onion” diagram below. 

Onion Ecosystem

A feature cell is an example of a context boundary that should not contain more than three to five people. A team is a context boundary that should reasonably max out at around seven to nine people. By the time we get to 15, a team becomes unwieldy.  Multiple teams can often be linked by a common mission or shared outcome. A tribe in Dunbar's terms, this group can often have between 30 and 50 people. We call that an ecosystem.

Once an ecosystem grows beyond five to eight teams, it's hard to keep identity and alignment.

Groups of 150 or more people are organizations dedicated to a common business or higher-level value proposition. These organizations are sometimes part of a larger enterprise, whose numbers span to the hundreds and thousands of people.

The impact 

The Global Payment Group could easily have become a victim of its own success as its growth overwhelmed the very team dynamic at its core. While agile ecosystems can grow organically, being intentional about scaling and by expanding Agile concepts to embrace larger contexts, makes it easier for teams to self-organize at scale.

Principles for scaling agile

  • Scaling Agile by defining a more complex or comprehensive methodology will only result in reduced agility. Instead, scale Agile by expanding the scope of Agile concepts used to manage teams.
  • Agile long-term planning expands team-level sprint planning to a larger scale using longer backlogs and graduated increments of time and size.
  • Simplify planning by scheduling work according to the throughput of the teams doing the work.
  • Ecosystem-level Kanban expands team-level Kanban to visualize the flow of larger increments of work across an ecosystem of teams that work closely together.
  • Ecosystem events are defined to manage a cadence of meetings to facilitate alignment across teams and their stakeholders. The exact number, frequency, and outcome of ecosystem-level events will vary based on the context of the ecosystem.