Agility at Scale

Agility at scale - blog 1

Scaling Agile Through Social Density

When it comes to scaling agile, a lot of organizations reach out for the closest scaling framework. While scaling frameworks can contain some good advice, at least for a particular context, the unfortunate reality is the essence of agility can often get lost as organizations attempt to roll out a big, standardized, one size fits all methodology.

What often gets missed by the “more Agile process is required to scale” camp is that Agile work because they create an environment where people engage in teamwork. The whole point of Agile is to create a space where people can form into hyper-collaborative groups to co-create value to create the condition where teamwork can thrive. 

Agile done well results in an environment of high social density. End-user contact, radical transparency, and various feedback loops all contribute to this concept of social density. 

Social density is a concept that can and does scale.

Look for ways to scale social density to larger organizational constructs. Instead of scaling by adding controls, think of scaling as ensuring the right social density exists beyond the scale of a single team. Identify opportunities to apply the teamwork to larger contexts and to make it easier for people to collaborate across various team boundaries.

Some examples of various context boundaries coming from my work with agile teams include:

• Feature Cell temporary close-knit group of 3-5 people that work on a single feature for a sprint or two
  

• Typical Enterprise Agile Team – A (yes oversized) team, that is still within a person’s socially active number of 15 people

• Ecosystem A larger network, with reasonably frequent engagement, that can share a common mission or higher level outcome – topping out at about 50 people

• Larger Organizational Units – at 150 people an active identity can be shared, and once we get to larger numbers 500 -1500- the best we can expect is cultural associations and identification.

As an example, when working with a team in Scotiabanks’ Global Business Payments group, we were trying to determine how to handle increasing demand being placed on that team. A victim of it’s own success, the team was taking on more and more work, and increasing it’s team size to an unwieldy number.

The team was organically separating into smaller groups to deliver different features. The grouping wasn’t always clean and we saw all kinds of churn and confusion, but we also saw the kernel of a good idea.

Team members, for the most part, felt they all had a common identity and structure that they wanted to keep despite how big they were becoming. Their answer was to divide the team into three separate but closely associated pods. 

Each pod would be responsible for the detailed delivery work of small numbers of features over time. A thoughtful combination of pod dedicated and cross pod rotation ensured that both a pod and higher “ecosystem” identify emerged. Visual Flow management and cadences at both team and ecosystem level were used to keep the larger group aligned and to understand what parts of the flow would require tighter integration across and when pods could work in a more autonomous way. With a minimum of fanfare, the first payments ecosystem was born!

Using the concept of cells, and Ecosystems is an excellent way to scale Agile in a way that suits the needs of your teams, and leverage the parts of agile that can scale to larger organizational contexts.

Agility at Scale - Blog 2

Teaming is a Verb

Many would say that the stable agile team is our core building block for an organization trying to increase their agility. Teams aren’t your core building block, the act of teaming is..

This might seem like an unnecessary distinction. But you can have teams where very little teaming / teamwork taking place. Likewise you can have very effective teaming take place in the absence of stable agile teams.

Heidi Helfand, in her excellent book Dynamic Reteaming, challenges the “stable” part of the team definition, and ask readers: If a team is more highly changeable, in the case of a hypergrowth start-up, is it still a team? Helfand posits that dynamic teams are still teams.

When two people get together to collaborate on a common outcome, they become a team! We often perceive teams as something set by management, an official organizational boundary used to group people together. This is at best a partially true statement. While management often (but not always) sets up the original scaffolding,  true teams are a result of the active, living interactions between individuals. We can’t have a team if people aren’t teaming. Teaming is a verb!

So teaming is the act of people coming together to deliver value. It is the act of hyper-collaboration. Establishing trust, understanding each other’s strengths and weaknesses, engaging in positive conflict, working toward shared outcomes, and holding each other to account while having each other’s back. It is this behavior that is the fundamental building block of any organization that wants to deliver value in the face of uncertainty. Teaming is the core building block of organizational agility.

Teaming allows us to get organized in a way that respects our humanity by placing people front and center. When we engage in teaming, we deliberately place our trust in others; we accept that we collaborate to generate value.

There have been a lot of talk about the “death of agile teams”. I like to take a more nuanced view. Agile teams, in my experience, are really a means to introducing the behavior of teaming, but are only one means of doing so, albeit a foundation alone.

The whole point of agile stable team is to provide a first, safe container for people to form into groups and collaborate on the delivery of value. There are other containers, which I will discuss in later posts, but teaching people to collaborate well inside a team is a great first step. But it is far from the final step. Nor is it the only way to start.

Agility really doesn’t start to take place until people start moving away from siloed work to shared work.  In fact, a key tenet of early forms of Agile is that an individual task should always be worked on by a pair of people, not an individual. Other agile concepts that are examples of teaming include:

Teaming is a concept that scales to the team-of-team level. Teaming encourages a counterintuitive philosophy that work should not travel across teams, this creates a hand off! Instead,  people travel toward the work. If we want the concept of Agile teams to scale, then we do everything we can to avoid working in a silo. We need to scale the concept of teaming. This means people need to pickup and leave the comfort of their own team when the work calls for it. They get as close as they can to the work and the people they are depending on to get the work done. The old fire-and-forget model does not work. Not between functional departments, but also not between agile teams. Instead of handoffs, it is better to manage these dependencies through interactions based on teaming, but this time our teaming takes place across teams.

In that vein, there is a here is a teaming tongue twister.

Team members need to team with other team members from other teams to be an effective team at greater-than-team scale.

When we use teams as a container to encourage teaming, we get the best of both our formal structure (the team we are in) and our dynamic structure (the teaming we do). It’s an approach that places our humanity front and center.