Organizing Toward Agility: Summary & Notes

I am back again with another summary and notes, and this time it is a book from Jeff Anderson (Agile by Design Inc.). His previous work on Agile Org Design had a significant impact on me, and his latest book, “Organizing toward Agility: Design, Grow, and Sustain Self-Organizing Structure at Scale” provides practical tools, real-world examples, and the knowledge available to all professionals.

If you like this summary, please do check out and buy his book. Click here to check out his book on Amazon.

Secondly, please feel free to check a few exhaustive summaries that I have done here on Medium.

If you are curious about versatile Agile Org Design or are a practitioner, please join me in May for a 1-day workshop titled “unFIX Foundation Workshop”. You will learn real world applications, practical tips and techniques, how to solve complex structural challenges in Organisations, how to resolve (and not coordinate or accommodate) dependencies etc. You will also see integration & further exploration of Jeff Anderson’s work (as described in this book) with unFIX as an added value proposition that you will not find elsewhere. Here is the link to the 1-day Workshop scheduled in May, 2023— https://unfix.com/event?id=X93qVQaN

Summary

Organizing Toward Agility

The goal of this book is to offer a new way to create value at an enterprise scale, one inspired by Agile thinking. Jeff aims to provide methods and examples showing how ideas like self-managing teams direct market access, and continuous feedback can be expanded upon to function in an enterprise setting. Agile comes in many flavors and methodologies — for instance, scrum, Kanban, SAFe, and Extreme Programming — and while they each differ in their specifics, they are all based on a common set of principles. For the most part when we use the term, we’ll be referring to a simpler definition:

Agile is a strategy to help organizations that face increasing market uncertainty by forming self-managing teams that have the autonomy to decide how value is created for their customers, enabling those teams to achieve their outcomes through intimate, direct, and frequent market contact.

Part I The Team

Chapter 1: From Industry to Uncertainty

Why do so many organizations seem so dysfunctional? It starts with how businesses view their own people.

Before 1850, Craft Manufacturing Age consisted of:

● Local markets,

● With very little cross-pollination between markets, and

● A high degree of custom-built solutions

From 1900–1970, Industrial Age offered:

● Fast-growing, spacious markets,

● With relatively little competition,

● Monopolies and oligopolies, and

● Sluggish markets

Finally, from 1970 onwards, Age of Complexity now offers:

● High-dynamic value creation,

● Global, high-competition markets

● Return of more individualized demand, and

● Mass customization

It turns out that the industrial organization is a victim of its own success. All of this innovation is making it feasible for customers to ask for products personalized to their exact needs, wants, and tastes. So that design-it-once-and-repeat-for-everyone idea is pretty much out the window. This all adds up to an era typified by volatility, uncertainty, complexity, and ambiguity — by VUCA, a term first introduced by the US Army War College in response to the “multilateral world perceived as resulting from the end of the Cold War.” VUCA has now been repurposed toward strategic leadership theories focused on discussing the great changes organizations face.

INDUSTRIAL ERA ORGANIZATIONS VERSUS MODERN ORGANIZATIONS

Organizations in the industrial era prioritize command and control, with directives coming from the top and information flowing from the bottom. In turn, the top of the organization then issues its next set of directives. But there are some fundamental issues with the industrial era organization in the face of market uncertainty. As uncertainty increases:

● The top of the hierarchy doesn’t have the context required to make the right decisions. The wrong decisions are made.

● To make decisions, it takes too long for the top to process information from lower levels of the organization. It takes too long to react to market change.

● Accountability is taken away from the lower levels of the organization.

● Internal departmental objectives take more focus than market outcomes do.

Organizing for the modern world requires that we decentralize authority into teams with the skills and permission to operate autonomously, iterating and improving based on market feedback.

THE WAY WE ORGANIZE IS CHANGING . . . SLOWLY

The modern organization is structured around decentralizing decision making to teams that have the autonomy to own outcomes through frequent market feedback. Moving toward a more people-centric organization requires that we promote trust, give up control, grant ownership, and overcome our fear of failure. The change to modern organizational models is highly synergistic when growing into a human organization focused on using profit and growth to make the world a better place. Your value network of people already exists where you work; you just need to make it your official, core organizational operating system.

Chapter 2: Agile Teams

A little over five years ago, I worked with Sean Deschamps, a fellow coach at my consulting firm Agile By Design, to help Scotiabank’s global payments group adopt Agile organizational principles on one of their projects. Scotiabank was investing heavily in the reorganization, but this investment had not yet made its way to the payments group. Sean’s impression of the dire state of affairs when he arrived was that the place had been defeated a long time ago.

I noted a deafening silence. I wondered how this could be a place where work was getting done, especially the complex kind of work that required constant collaboration.

AGILE HELPS PEOPLE TO TEAM

In this age of uncertainty, the team is the organizing construct that is best positioned to create value. One of the most compelling aspects of Agile is the wealth of concepts dedicated to getting a team up and running. Agile has a wealth of good practices that can help us operationalize the modern team, and it gives us a frame to help people in the team react to feedback and continue to grow and learn.

Teams are the organizing construct that bring the motivation, collaboration, and feedback required to deliver value in the face of constant change.

In the rest of this chapter, we will examine the key traits of Agile teams.

RADICAL TRANSPARENCY

Many Agile methods have the side effect of contributing to an environment of radical transparency. Visual backlogs, visual workflow, visual maps, and visual models all contribute to this radical transparency. Modern work is not factory work, but knowledge work. We (mostly) aren’t processing physical goods. Our inventory is invisible, the work is often not repeatable, and our progress is hard to quantify. This lack of common understanding kills agility.

Radical transparency is a great first step toward better behavior. It is harder to avoid uncomfortable truths, to be political, and to work on things that don’t add value. Radical transparency makes the consequences of people’s actions more obvious, both good and bad.

Starting with radical transparency will increase shared understanding across all participants.

CROSS-FUNCTIONALITY

Grow team cross-functionality and increase autonomy over time.

Most areas of enterprise, and especially IT, are rife with overspecialization. Separating testers from analysts, software designers from developers, back-end developers from front-end developers has more to do with following historical precedence and protecting people’s egos than with doing what works.

Cross-functional teams are a shift away from traditional attitudes toward specialization. The idea is to equip each team with all the skills they need to achieve their outcome. We want people to be able to pinch-hit for each other, and to learn how to take on numerous roles. This is a balancing act; we still want deep, specialized expertise in many of our people, but we balance this with the need for people to gain adjacent skills. When we put teams together with diversity in mind, we bring distinct skill sets, ranges of experience, and a mixture of perspectives. Instead of using management to move work across departments, we bring the right skills to the team. Radical transparency helps us along the journey.

FREQUENT MARKET FEEDBACK

Adapt to market feedback frequently, iterating toward success and reducing the need for command and control.

Frequent market feedback is the corrective mechanism teams use to stay on track. It is an unambiguous way to understand whether what is being built is leading to the right outcomes. Teams can start down the path of increasing market feedback by using Agile techniques to thinly slice work so it can be delivered in smaller increments of value to the market. Agile also encourages teams to only work on a small number of those increments of value at a time. When a team works on a small number of small things, we get an earlier opportunity to validate the value of what we are working on with our market, increasing the frequency of feedback.

TEAM SPACE

An Agile team is made up of a small and stable roster, with an established team space, so that they can develop the social bonds required to be effective.

The team concept cannot work if individuals do not learn to act as a team. Yet many underestimate the investment required for individuals to operate with a sense of real teamwork. A team space dramatically accelerates people’s ability to, well, team. Historically this presence was created through dedicated physical space. In our current climate of mandated working from home, this sense of presence needs to be created virtually.

OPERATING NORMS

Establish operating norms for your team, such as planning, stand-ups, and reviews, and hold them at a steady cadence.

Effective teams will often establish a set of operating norms to help align and interact with each other as a team. Agile provides a specific set of operating norms for planning, review, improvements, and daily coordination. For instance, a short iteration is started with a planning session and ended with a review and retrospective. Short stand-up meetings occur daily. Teams often learn to decouple these sessions into separate cadences and to vary the type and frequency of sessions according to their needs.

STABILITY AND DEDICATION

In the traditional working world, team members often do not have a chance to gel into anything cohesive, simply because team membership is thought of as a temporary and/or part-time commitment. The team roster is constantly changing. No one is truly a member of any team. Teams cannot establish meaningful norms, and team members never really learn how to work with each other. The team never actually does any teaming. Stability and dedication are both necessary to maintain a stable social boundary.

SMALL AND SOCIALLY DENSE

We also want to keep teams small, somewhere between five and twelve people. Metcalfe’s Law, which states that the effectiveness of a network is proportional to the square of the number of connected devices, can be interpreted to show how many communication pathways exist based on the size of a social grouping. For example, for every 3 members, there will be 3 connections. But every 4 members will make 6 connections.

Organizational Constraints:

1. Deliver market value through small, stable, cross-functional, self-organizing teams that take advantage of radical transparency, full-time membership, focus, and frequent feedback.
2. Use functional departments to grow capability in a functional skill set; avoid managing value creation through functional managers.

Teams deliver value, while functional departments grow expertise. Leading value creation and leading the development of expertise are two very different leadership activities, and the two should not be confused with one another.

Chapter 3: Teaming Is a Verb

Many people would say that a team is “a bounded and stable set of individuals interdependent for a common purpose.” Heidi Helfand, in her excellent book Dynamic Reteaming, challenges the “stable” part of the definition. She asks readers: If a team is more highly changeable 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. This notion of dynamism leads us to the idea that teams are not merely some boundary that we use to group people together. Teams are the set of active, living interactions between individuals. We can’t have a team if people aren’t teaming. Teaming is a verb!

Teaming is the act of people coming together to deliver value.

TEAMING IS HOW HUMANS GENERATE VALUE

Traditionally, we place people into functional hierarchies or project teams. Managers assign work to their subordinates, which often gets pushed down to the exact person and down to the exact task. That is an approach meant for machines, not people. 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.

Team members team with other team members to effectively team!

This is so because of the following:

1. We can adjust how we are organized based on unforeseen changes.
2. We grow our skill sets and increase learning and exposure across different roles and skills across the team.
3. We reduce the impact of anyone leaving the team.
4. Our quality goes up as a diverse set of perspectives are simultaneously applied to the work.
5. We reduce the impact of bottlenecks as we pinch-hit as required to complete unfinished work.

Organizing Constraints:

Use teams and other safe, trusted social spaces to enable the majority of work to be done in co-creative or hypercollaborative ways, such as in pairs, mobs, swarms, or cells. This is known as teaming.

TEAMING WITH KANBAN

Kanban, originally from lean manufacturing, has been adapted to be a formal method that is suitable for knowledge work, thanks in large part to the efforts of David J. Anderson. Unlike many of the other approaches, Kanban is really a tool kit for people to design and operate their own system of work. Kanban asks you to enhance the way you work, whatever that way of work is, through the following fundamentals:

● Visually define and manage your workflow and all of your work that is in that workflow.

● Collaboratively refine the agreements that define how work flows from one state of completion to the next.

● Limit the amount of unfinished work in the system at any one time.

● Establish cadences that fit the needs of your team, your customers, and other teams you work with.

● Improve the performance of flow by constantly identifying bottlenecks, blockers, defects, and other impediments, and introduce improvement experiments that are verified using quantifiable metrics such as lead time and Throughput.

Kanban works especially well when people are able to move past any official job or role they have to come together and solve a problem that is impacting the flow of value. And that is done by making the whole work process visible to each member of the teams involved.

THE TEAMING VALUE NETWORK

We can use Kanban to agree on how and when people can move into new positions, upstream or downstream, to collaborate with others. Value networks can be thought of not as handoffs across teams, but as concentric circles of teams where people overlap to ensure work flows smoothly. We can think of connecting our people across teams as linking; linkers are people who collaborate across team boundaries. And linking is something that is pretty easy to visually manage using a Kanban system.

THE PAIR

Pairing is when two people work on a single piece of work, typified by only one person on the keyboard at a time.

Pairing is an excellent way to level people up and improve their skills. Stepping a bit away from the keyboard-swapping notion of pairing and thinking about pairing as the act of two people working closely on one thing, we can see that pairing provides a lot of value when the members of the pair belong to different functional disciplines. Example pairings include:

• Marketing and production

• Operations and everyone else

• Call center people and everyone else

• UX and developers

• Developers and analysts

THE FEATURE CELL

A feature cell is a subgroup of the team that comes together to deliver a coarser piece of work on the team’s backlog.

The idea of a cell is that it often makes sense to explore and even deliver a piece of work with a tight grouping of people. A group that is smaller than the team but larger than a single individual or single pair on the team. Often larger teams — say, more than five or six people — struggle to effectively collaborate across the entire body of work that the team is delivering. One approach that teams can take is to ask people in the team to form into a cell for a short period of time. For example, a feature containing several stories. Once the work is completed, the cell can either take on the next piece of work or dissolve so that the people can be available to take part in a new and different feature cell.

THE MOB

Mobbing is when the entire team closely collaborates on a single piece of work, again with only one person on the keyboard at any one time.

A mob is like a pair but taken to the next level. In a software development setting, mob programming is a practice where only one person in the team is allowed to program at a time. Woody Zuill pioneered the first instance of mob programming during his time at Hunter Industries. The keyboard is rotated frequently across each member of the team, sometimes at fifteen-minute intervals, sometimes less. The rest of the team supports the flow. One person may play the navigator role. Others may be exploring new technology, looking up information in databases, you name it. Anything but hands-on programming.

The team at Hunter Industries set up the entire room to support the mob programming approach. Computers, projectors, and desks were all arranged to create focus on the one piece of work being completed by the (only) active pair. All interactions were done as a team. Some of the benefits? Less thrashing, higher focus, freedom from “overhead practices” like estimating and scheduling, better communication, lower technical debt, less team politics, and fewer meetings. The team at Hunter and others who have tried mob programming have actually reported higher productivity.

THE SWARM

A swarm comes together across roles, teams, and functions to solve a sticky problem that transcends official organizational structure. Kanban is designed to facilitate the swarming required to eliminate bottlenecks and maximize the flow of value.

A swarm is any group of people, more than a pair, that assembles dynamically to accomplish an outcome. This group swarms often by coming together to solve a problem that is preventing work from being completed. They swarm to collaborate on improvement experiments or to resolve a persistent customer complaint. When a bottleneck forms in the flow of work, often made apparent by an excess of work in progress (WIP) in a particular column in the Kanban, then people agree to drop what they are doing and swarm around the bottleneck until the flow is restored.

Chapter 4: Roles and Jobs for Team Members

Jobs in the traditional organization are overspecialized and specified and are a poor fit for the collaboration and dynamism required to succeed in an uncertain world. The idea behind distinctly defining roles is that if we define what everyone is signing up for up front, then it becomes much easier to work together as we scale up. Sounds great, doesn’t it? Not if we want living, thinking beings to thrive through teamwork.

JOB AUTOMATONS

Employment in any organization comes with a job that has a very specific definition. This type of job description puts the focus on individual effort rather than on interactions across individuals.

A job automaton does their work according to the letter of their job description. The problem is that most job descriptions are out of date the moment they are written, so job automatons consistently fail to deliver on outcomes that require adapting to change. If we want to create an environment where people focus on constantly learning and continually adapting to create value, we need to discard antiquated notions of jobs and roles. We need to refrain from approaches that start with us getting told what we can and cannot do.

LET THE TEAM DECIDE WHO DOES WHAT

Think of jobs like a professional sports team: we need both expertise and pinch-hitting in order to succeed! In the modern age, we want to encourage people to play more than one role. Consider this example of role churn at Scotiabank’s billing lab, which was tasked with creating a consolidated billing system for its diverse suite of cash management products. Margaret Walczyk, the tech lead in the billing lab at the time, recounted her experience this way:

There I was, the technical lead, with a project owner and a couple of seasoned architects, all trying to “manage” a team of thirty-plus folks. It felt like we were overriding each other frequently, which negatively impacted others in the lab. It was a bit of a mess.

At first, some of the upper management (VP level) wanted to resolve the situation by handing down distinct roles, responsibilities, and accountabilities. The team suggested a different idea. They took a stab at coming up with their own answer. They started with the leadership group and facilitated an exercise in which each person listed the skills that each team member brought to their role. They found that there were a few unique things that really belonged to only one role.

But there was a lot more overlap in terms of what everyone wanted to bring to the table. They made significant progress by categorizing this overlap:

● Core skills: things that we identified as foundational to the one role

● Adjacent skills: things that we felt were core to our role but also core to other roles

● Peripheral skills: things that we could do in a pinch, and maybe even wanted to learn how to do.

The result was higher trust. Not only did team members trust each other more, but the executives trusted the people in the lab.

Organizational Constraints:

Design job specifications so that people can play many different roles.

Design jobs so that we can encourage people to play many different roles, defined around behaviors that focus on collaborating with other roles to achieve valuable outcomes.

GROW HELICOPTER-SHAPED PEOPLE

We want cross-functional individuals inside of our cross-functional teams. We want people to learn, growing, and expand their skills. In other words, we want to encourage the development of T-shaped people. Your knowledge literally expands deep and wide, like a T. Perhaps a better description is helicopter-shaped people. We want people to go wide in a number of directions. Your depth of expertise still matters, but its real value comes from educating others on how to apply it.

Chapter 5: Truths, Myths, and Lies About Teams

Many organizations manage their Agile teams with a traditional management layer, a hierarchical organization. They struggle to make Agile teams truly work for them in an enterprise setting. They struggle to grow teams that exhibit independence, build teams that are responsible for end-to-end value creation, and to foster teams that can operate with true autonomy.

To address these challenges, we need to tackle what have become sacred cows in the Agile space.

THERE ARE NO INDEPENDENT TEAMS

OK, time for our first sacred cow, the idea of the independent team in an enterprise. There are no independent teams, but there can be autonomous teams. Perhaps we are talking about a software application delivery team. The team has accountability for everything from prioritization, through delivery, all the way to rollout and operations. Sounds like a truly independent team, right? Now think about all the things that the team needs to deliver on any one increment of value. Is there another team in our organization that does market or competitive research? Do we rely on this research to make decisions? Should we? Is there a common business model the team is leveraging? Do other teams have input into it?

In an organization of any scale, the answer to at least some of these questions will be yes.

STABLE TEAMS ERODE AGILITY

In the face of complexity, your team structure will always be a little bit wrong. Static team structure will result in a loss of agility over time.

Now that we have taken a shot at team independence, let’s take a crack at team stability. I’m sure this one will get some people’s backs up. Stable teams erode agility. There, I said it. I want to ask you to think about what Agile is trying to address.

Uncertainty. Complexity. Change.

Perhaps some other team has those missing skills we need to deliver value. Couldn’t we send that portion of the work over to the other team? We could, but now two teams need to coordinate to deliver value, which interferes with each team’s ability to independently self-organize. Maybe a piece of work involves more effort than we thought. Can’t we keep the team the same size and take longer to deliver? We could, but we may delay feedback and learning, and depending on how important that feedback is to the team, we could end up delivering the wrong thing to the market.

We are working in a world where change is constantly accelerating. And therefore, our team structure, no matter how well designed, is always going to be wrong. But that’s OK. Just keep changing according to the needs of your team and your ecosystem.

AGILITY DOES NOT COME FROM AGILE TEAMS

Your organizational agility won’t come from improving the agility of your teams in isolation.

There is nothing wrong with a strong team focus. We want a strong team focus. But we want to avoid a team focus becoming a team-only focus. Unfortunately, Agile has a track record of successfully optimizing the health of individual teams but having no effect on organizational value creation. In some cases, team-level optimization has even caused harm to organizational value creation.

Let’s take an example: Team Software is a software delivery team that works with Team Training, a team that delivers end-user training to support users based on that software. Team Software is rocking it! They deliver and they deliver quickly. But Team Training just can’t keep up. They can’t get support users trained fast enough to keep pace with all the changes to the software that Team Software is making. Worse, Team Training starts to compromise training quality to maintain pace. This leads to poorly trained support users. These support users make mistakes using the software, which causes real problems with actual paying customers of the business. As a result, customers stop relying on our business, and demand for Team Software’s product goes down.

None of this is apparent from team practices, team metrics, or a single-team focus.

BUT (AGILE) TEAMS DO WORK IN THE ENTERPRISE

Before we lose all hope, let me pause and say the concepts of Agile teams and teaming can and do scale to meet these and other challenges we see in the enterprise. To do so, manage dependencies through teaming, and deliberately evolve team structure to avoid Handoffs.

Scaling Agile teams requires that we take the time to understand the reasons behind why Agile works and why Agile teams work. What is the “thing” we are trying to scale exactly? In my experience, we are scaling the ability for our people to form into hyper-collaborative groups that leverage rich (market) feedback to co-create value.

Part II The Ecosystem

Chapter 6: The Ecosystem of Agile Teams

I’ll use this section to discuss how to grow structure to meet growing demands on the team.

SAFE, EFFECTIVE HYPERCOLLABORATION AT LARGER SCALE

OK, so your team needs to scale. Let’s break out the scaling framework, right?

Wrong. What the “more Agile process is required to scale” camp seems to miss is that Agile teams work because of the social density that comes from a transparent team environment.

Social density is a concept that scales. Instead of scaling by adding controls, think of scaling as an act of ensuring the right collaboration is happening beyond the scale of a single team. Look for ways to scale social density to the larger organization.

SOCIAL DENSITY THROUGH CONTEXT BOUNDARIES

You scale Agile by scaling social density, by applying the team and teaming concepts to larger contexts, not through the extra methodology and extra controls.

Dunbar’s numbers suggest that there is a cognitive limit to the number of people one can maintain stable social relationships with. It suggests that close-knit groups involve approximately 5 people. A person’s socially active number, one where they maintain a fair amount of social contact, is about 15 people. A larger network, one where people can still interact and engage with each other at some reasonable frequency, caps at about 50 people.

Using this information, we can set up organizational context boundaries. A context boundary is a boundary we can place around a group of people that shares a particular context space. Larger context boundaries contain smaller context boundaries: in other words, contexts can and do nest.

For instance, a feature cell is a context boundary that should not contain more than 3 to 5 people. A team should reasonably max out at around 7 to 9 people, and it gets pretty unwieldy when we get close to 15. Multiple teams can often be linked by a common mission or shared outcome. Referred to as a tribe in Spotify lingo, this group can often have between 30 and 50 people. I call this association of teams an ecosystem of Agile teams.

When rethinking your organization, there are two levels of context boundaries you will want to pay particular attention to early on. The first, obviously, is the team. The second context boundary is sometimes less obvious: the team-of-teams structure. This is what I am going to call an ecosystem of Agile teams.

MAPPING OUT AN AGILE ECOSYSTEM

You will likely find yourself in a situation where there is a desire to move to a more Agile, team-based structure in a less organic way. In the spirit of moving forward with imperfect information, we can work with volunteers to map outcomes of both work products and capabilities and then collaborate to identify people and their team structure that will bring these capabilities to bear.

Impact mapping is a technique in which you map the behavioral changes (impacts) of your users in response to organizational goals. Once you group impacts by actors, personas, or user categories, you then add deliverables that could support those behavior changes. Related items are connected visually through a mind map.

For example, we might ask linked questions like:

● Why are we doing this? (Business Epic, Architecture Epic, Business Goal)

● Who will help us achieve our outcome? (Actor, Persona)

● How should behaviors change? (Impacts, Obstructions)

● What can we do to support the impacts? (Features, Manual)

Impact mapping allows us to look at the relationship between a large collection of work, outcomes, and market actors, providing information in a way that makes it easier to make decisions about structure and about how best to organize around the market outcomes you want to achieve.

DEFINING YOUR TEAM MODEL IN FOUR EASY STEPS

We used impact mapping within a four-step process:

1. Domain clustering the medium-term (three to six months) goals for the organization; identifying common themes and synergy.

2. Impact mapping each domain in order to get a better understanding of initiatives and the behaviors that we are looking to change in our stakeholders.

3. Drawing boundaries on the impact map to define team mapping of specific impacts; analyzing the skills required to deliver potential initiatives.

4. Clustering related initiatives, unexplored domains, and operational processes; creating team definitions.

Chapter: 7 Operating an Ecosystem of Agile Teams

If we want to stay organized, we will likely need to put focus on the day-to-day operations of our ecosystem. Really, what we want to do is find a way to scale our Agile concepts with simplicity and grace. First, let’s provide a description of what we mean by scaling. When we connect teams into a common ecosystem, it becomes both easier and more necessary to scale our agility horizontally. When we scale horizontally, we connect concerns typically considered upstream or downstream from a core Agile team. Ecosystems are more likely to have concrete missions and measurable objectives than a single team. They are more likely to have accountability to concrete business outcomes.

Of course, we are also scaling Agile vertically, simply by the act of grouping Agile teams into a cohesive ecosystem. Scaling Agile horizontally is about coordinating work within larger and larger organizational boundaries. It is also about being able to manage larger missions, or outcomes. When scaling horizontally, we care about both the strategic perspective and the tactics of managing interdependencies, common platforms, and related enterprise concerns.

SCALING THROUGH THE PRACTICES WE ALREADY KNOW AND LOVE
Some of the simple behaviors we see in an Agile team that can and do scale include:

• Enhancing collaboration within teams using visual story/task management and definitions of done

• Synchronizing people using sprints and ceremonies

• Conducting team planning with product and sprint backlogs

We can scale Agile to operate an ecosystem of teams by abstracting these concepts into a collection of behaviors that can be applied at the ecosystem scale. Let’s go through some of these practices with an eye toward facilitating the operations of an ecosystem of teams.

LONG-TERM PLANNING

Agile long-term planning expands team-level sprint planning to a larger scale using longer backlogs and graduated increments of time and size.

Long-term planning is the act of applying team-level sprint planning concepts to a larger scale.

When we think of team-level planning, we often think of teams that:

● Conduct release planning, where epics are placed into a product backlog

● Conduct sprint planning, where epics are decomposed into stories and placed onto a sprint backlog based on team velocity

Applying planning at a larger scale includes expanding our concept of a backlog to what I call a graduated backlog. A graduated backlog encompasses both a larger time horizon and coarser-grained value increments.

These horizons have orders of magnitude that are less precise the further away the work is from being started. When we don’t expect to start work for a long period of time, we expect it to be poorly understood. As the team completes the current work, items in the backlog are shifted to the right as the start date of the work becomes closer.

Teams can anticipate the reasonable start date of items in the backlog by estimating their throughput. Agile teams deliver value by breaking larger requests into smaller increments often known as stories. The more teams deliver, the better they can anticipate their average story throughput per month or per week.

ESTIMATE AND TRACK THROUGHPUT

Simplify planning by scheduling work according to the throughput of the teams doing the work.

Once our stories are small, we can make the exact same observations provided through story estimating by simply estimating and then counting the number of stories that flow through our system of work. An emphasis on throughput can save a lot of time and effort from the team; they no longer have to debate small differences in complexity between each story, differences that do not matter if we look at the medium or long term.

Once we can use a team’s story throughput, we can then estimate items in the backlog in terms of the number of stories in it. This is where estimating using relative sizing can really shine. We can use relative sizing to quickly estimate new work by asking, How big is this piece of demand compared to something that was previously delivered? Is it bigger or smaller? By a lot or a little? Using this approach to estimating story counts for larger items becomes easier over time.

The first step to creating a backlog is to stack-rank backlog items against each other — or, better yet, against other units of value that your organization has previously delivered. This allows you to quickly estimate an increment of value relative to something else.

GETTING BETTER BACKLOG CLARITY THROUGH STORY MAPPING

If the goals are still not clear enough for you to guide the organizational design dialogue, consider refining one or more items on your backlog through a story mapping session. Story maps allow you to map the flow of your solution in a hierarchical way. Story maps also allow you to define independently releasable thin slices of value or MVPs. This helps you prioritize small units of value that you can release to your customer.

Initially, estimating is just swag informed by experience! Where there are too many unknowns, teams can spend more time exploring the work using techniques like story mapping, design modeling, or even actual delivery. As the delivery start date approaches for the work, deeper dives can be used to get a more accurate understanding. It is important that all members of the ecosystem have access to this view and can spend some time looking at it holistically and asking the questions:

• Do any teams need my help?

• How can I more effectively team with other teams?

• Should any of the teams consider reteaming?

• Should our team be working on a different outcome?

ECOSYSTEM-LEVEL KANBAN

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.

As the complexity of our ecosystem increases, we can use Kanban to enrich our team members’ understanding of the work and scale team-level visual management to the entire ecosystem. To do so, we abstract the work each team is doing to a higher level, each ticket representing an outcome, or perhaps a feature or thin slice. With the right attention to an ecosystem-level Kanban system, people can start to form muscle memory in terms of how to collaborate in different configurations, which helps with teaming across teams. People start to transition their thinking from a static structure (team or otherwise) to the set of organic interactions that promote flow.

USE VISUALIZATION TO ILLUSTRATE CAPEABILITIES AND EXPERTISE IN MORE DETAIL

Simple flags and other annotations can be used to articulate which capabilities are needed to complete a piece of work, as well as which capabilities a team within an ecosystem is in possession of. I have seen people use clever annotations, as well as team/individual “hockey cards” with simple icons to indicate various skill sets.

DEFINING ECOSYSTEM-LEVEL EVENTS

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.

On an Agile team, events are an important part of maintaining an operational cadence. It is one way teams can maintain a sense of predictability in a sea of change.

Events are scheduled either according to a set cadence — for instance, we may run a planning session once every two weeks — or according to certain WIP limits — for instance, we may run planning whenever we have three or more features that are in the “analysis done” state of our Kanban. While teams are free to choose the operational cadences they want to use, the list of team cadences is relatively standardized, as are the attendees. Most teams will have events that include planning, reviews, retrospectives, and stand-ups, with some teams combining a few of these together. Unlike teams though, the right Agile-style event cadences for ecosystems will be much more dependent on your context. For instance, teams that are tightly coupled on a program will use different events than teams that are more loosely coupled by a common mission.

Potential ecosystem events can include mirroring the team-level events (e.g., planning, stand-ups, retros, and reviews) as well as potentially ecosystem-only events such as shared stakeholder replenishment, long-term planning, team-to-team synchronization, rotating stand-ups, and open spaces.

Chapter 8: Teaming in an Agile Ecosystem

In this chapter, I’ll dig deeper into some patterns that explain different ways team members can interact and collaborate across teams.

AUTONOMY, NOT INDEPENDENCE

In an enterprise, it is more important to maximize team autonomy — in other words, their decision-making power — than to achieve true independence from other teams.

When talking about a team operating in the context of a larger organization, it is important to separate team independence from team autonomy. An independent team works in isolation of everyone else. In contrast, an autonomous team is a team that has the freedom to determine how much independence it needs to self-organize toward value creation. Team autonomy isn’t about going it alone; it is about giving the team the autonomy to choose who it depends on. An autonomous team can and will depend on other teams, but it will do so with purpose.

TEAM MEMBERS TRAVEL TO THE WORK; WORK DOESN’T TRAVEL ACROSS TEAMS

Dependencies across teams are best managed through teaming, encouraging team members to the work, rather than work being dispersed across teams.

Perhaps one of the most counterintuitive ideas introduced to me by David J. Anderson’s work on Kanban is that work does not travel across teams. People travel toward work. If we want the concept of Agile teams to scale, then we do everything we can to avoid working in a silo. In simpler situations, we can think of this traveling in terms of one team acting as a client while the other acts as a kind of provider. The team that requires something from another team is the customer, and the team with the dependency is bringing value to that customer. The provider travels to the client to team with them. The real world is often messier than this simple depiction of client and provider. People from different teams will need to temporarily come together for all kinds of reasons.

MINIMIZE DIRECT DEPENDENCIES; MAXIMIZE INDIRECT DEPENDENCIES

Where possible, turn direct dependencies that rely on work into indirect ones that rely on platforms and knowledge.

One way to manage dependencies is to think of value-creation activities as either direct or indirect activities. Even a team that fully owns its market-value creation will likely need help on what I will call indirect or enabling activities. Think of a sports team. The team is responsible for winning, but a lot more activities go into winning than playing the game — talent scouts, logistics, getting people into the sporting venue, career counseling. However, the team doesn’t necessarily want to do all of these things. The team likely wants to focus on the game. Likewise, in an organization of any scale, teams will want to maximize independence on direct-value creation and to retain autonomy for everything else, while actively receiving support from other teams.

There are three patterns that I have seen people use to effectively collaborate across teams, especially within a common ecosystem:

● the traveling team worker,

● the enabler, and

● the service provider.

The traveling team worker, or traveler, is someone who travels to another team for a short period of time to closely collaborate with them on a piece of work.

The enabler is someone who helps another team build their expertise in a capability that they possess deep knowledge of, perhaps a skill, role, or API.

Service providers perform just enough collaboration with a requesting team to understand their ask, then perform the bulk of work required to complete that request without the other team, perhaps conducting periodic feedback sessions with the other team.

Chapter 9: Reteaming in an Agile Ecosystem

An organizational model based solely on products will be wrong, a model based on customer experiences or customer segments will be wrong, and so will any other model based on anything but the market outcomes your organization is trying to achieve at this exact point in time.

STABLE TEAMS ARE EFFECTIVE TEAMS

Without stability, teams do not get the chance to gel, nor to achieve high performance. While stable teams are a worthwhile goal, overly focusing on keeping the team roster stable in a changing market can mean we end up with dependencies across teams over time.

INDEPENDENT TEAMS ARE EFFECTIVE TEAMS

On top of being mindful of stability, we need to be mindful that it is harder for teams to effectively self-organize if they don’t own a major portion of their scope of the work required to accomplish their outcome. However, independence can erode with time. The reality is that your team structure will always be catching up to changes in the demand feeding your teams. So, we have two problems:

1. It is very challenging for teams to work well unless they exhibit some form of stability.

2. It is also very challenging for teams to self-organize if they always have to work with other teams to get anything done.

The reality is that team stability and team independence are concepts that contradict each other.

INTRODUCING DYNAMIC RETEAMING

Dynamic reteaming is the act of continually changing teams to solve a variety of challenges, including the need for teams to be as autonomous as they can be.

In her book Dynamic Reteaming, Heidi Helfand strongly asserts that “whether you like it or not, your teams are going to change. . . . Recognizing team change as a natural occurrence is a key point. . . . In essence, team change is inevitable, so we might as well get good at it.” She points out how teams can pursue incremental reflection and adjustment to not only their product and process but also their team structure. According to Helfand, reteaming helps teams “learn together and do things they couldn’t do before. Reteaming brings possibility.”

In this chapter, we will look at different ways you can scale out Agile practices to help team members and management to facilitate the act of dynamic reteaming.

SHARED DISCOVERY AND INTEGRATION

Perhaps one of the most obvious things multiple teams need to do when working on a larger engagement together is collaborate on understanding what needs to be done, as well as validating that what was done matched that understanding. A Kanban system can be used to indicate when an epic, feature, slice, or whatever is ready for shared discovery, after which point teams go to work on their separate pieces, then come back to integrate their work and conduct shared testing. Exactly who participates in shared discovery, integration, and testing will depend on the context.

THE CROWD SWARM

Swarming is even more powerful when a crowd — a group that does not belong to any one team, group, or department — comes together to swarm on a wicked problem. The Kanban community has really made crowd swarming shine, showcasing numerous examples where attending an ecosystem-level or higher-level Kanban made it clear to people that they needed to form together outside of familiar organizational boundaries to get something accomplished.

PART-TIME EXPERTS

The part-time expert spends enough time with two teams to understand the context of both, making themselves useful as a part-timer. When one of the teams faces a spike in demand, or unexpected complexity, the part-timer switches to full-time on that team and significantly increases the team’s capacity until things get under control.

THE STABLE TEAM-FRONTED POOL

In this pattern, a subset of the team is stable. The stable teams require workers that are highly specialized, but each team has inconsistent demand. For instance, the channel teams may need integration developers with deep knowledge of working with the legacy back-office product. Because the need is inconsistent at the team level, but relatively stable at the ecosystem level, the back-office workers are organized into a pool.

When new work is brought into the team, someone from the shared pool assists with discovery and determines the amount of pool work required. The team staffs up or down from the pool as needed. Kanban WIP limits are used to ensure the pool is not overloaded.

THE DYNAMIC FEATURE TEAM

With dynamic feature teams, our ecosystem has completely moved away from the idea of official stable teams. Teams are determined by an ecosystem-level Kanban. When a new item is pulled into discovery, a subset of the ecosystem does enough exploration to determine who is required to work on it to completion. This information is shared with the ecosystem members, who can self-organize into a team.

Above all, avoid falling into the trap of laying out your teams so that they become a complex and interdependent value network, where nothing can get done without the work of multiple coordinating teams.

Part III The Enterprise

Chapter 10: From the Core to the Edge

The new organizational model moves away from the ideas of control, compliance, power, and authority and toward organizing around market-facing teams and systematically decentralizing decision-making, from a hierarchy of control and authority and toward a circular network of

markets we serve and outcomes we want to achieve.

When we scale, we still need to succeed in a world of constant change. Let’s pause and take a second to imagine a new model that addresses constant change. Instead of thinking about a hierarchy of control and authority, let’s think about a network of markets we serve and outcomes we want to achieve. Niels Pflaeging, in his excellent book Organize for Complexity, provides one such mental model. A core idea from Pflaeging’s model is that market pull is what connects our teams across an organization.

The activity of stakeholders external to the organization initiates market pull. One or more market-facing teams, placed at the “edge” of the organization, respond to this pull and as a result may request assistance from one or more support teams placed in a “core” zone, creating market pull inside of the organization. In effect, this new mental model for the modern organization is that of a value network, where feedback flows inward from the market, inward to the teams on the edge, and then eventually further inward to support teams at the core of the organization.

FOUNDATIONAL ORGANIZING STRUCTURES FOR THE NEW ENTERPRISE

The market is the outermost part of this organizing structure, made up of all groups that exert external pressure on our organization. Users, customers, researchers, regulators, and even competitors are all examples of market actors.

The next zone is the edge, made up of every team that directly engages with people in the market. Edge teams are organized to meet external market needs and can be formed around discrete outcomes, steps in the customer journey, market segments, products, or even specific technology systems.

The edge in turn acts as a market to the innards of the organization, known as the core. People in the core serve the edge, providing common support services such as security, people ops, legal, finance, infrastructure, and common platforms. The core is different from traditional support groups in that the services provided by the core are strictly voluntary. The core has to treat the edge as its market. This means if an edge team can find a better service outside of our organization, then it is free to do so.

THE MARKET

The market contains all external market actors, the edge contains all market-facing teams, and the core contains all support and centralized functions. The market includes all users, customers, support organizations, regulators, and even competitors.

The market is all the groups that exert external pressure on your organization. This list is not limited to customers and users but includes all stakeholders that influence the way your organization provides services to the market.

When redefining an organizational structure, we should start by identifying all of the players that our organization must interact with in order to deliver value to the market.

THE IDENTITY

The identity contains elements that foster alignment and inspire culture. Use lightweight and inspirational artifacts, not heavy road maps or blueprints. Articulating a meaningful purpose is a very powerful exercise when it comes to establishing identity.

Unlike other “zones” in our organizational mental model, identity does not define where people are placed or who they engage with. In contrast, the identity contains normative artifacts that describe who we are and, more importantly, who we want to be as an organization. There are some great examples of artifacts we can use to help establish our organizational identity. Almost all of these artifacts are informal and focused on telling a story, not on creating a false prescription of artificial precision. Good identifying elements include:

• Business models formed using the practice of business model generation

• Taking the time to establish a common set of shared values and beliefs

• Full participation of common rituals, such as shared morning updates, stand-ups, or periodic open spaces Publishing a “letter to ourselves,” a note from the CEO of the company to all its employees that explains the kind of organization we are, what we want to be, and our values that will get us there

• Developing and sharing a culture handbook

• Developing and sharing an organizational brand proposal

• A shared backlog of customer problems

ORGANIZATIONAL PURPOSE

Perhaps the most important aspect of establishing an organizational identity is the articulation of a common, meaningful purpose. Meaningful purpose motivates people to work together to achieve it. It gives us a sense of belonging, a community to engage with, and a chance to create together. When people can contribute to a meaningful purpose, the need for expensive and crippling bureaucracy slips away and people use values, not rules, to guide their decisions.

THE EDGE

The edge is made up of every team connected to the market. The teams in the edge possess the skills and have the authority to perform all of the roles required to make decisions based on market interactions. This means every market interaction! There are many responsibilities that can be performed by edge teams. Some of these include:

• Building new product features, deploying them to the market, and validating them

• Customer onboarding, maintenance, and support

• Market research, strategy, and business model generation

• Marketing and creative endeavors

• Vendor and partner management

• Engagement with regulatory bodies

• Organizational investments

ORGANIZING CONSTRAINT:

Place the majority of people in your organization in edge teams that are dedicated to achieving market outcomes.

THE CORE

The core contains all the teams that provide services and support to the edge. Unlike traditional enterprise support, the edge can choose not to use the core, and as a result the core teams must provide an excellent enterprise experience to the edge teams.

The core is made up of teams that are intentionally deprived of market contact. These teams serve the edge, providing services that the edge chooses to use. Virtually everything that you want to have some kind of oversight, consistency, economies of scale, or strategic perspective can go into the core. Some examples include:

• Regulation and compliance

• Finance or budgeting

• People operations (also known as HR)

• Legal

• Security and privacy

• IT

• Coaches

• Leadership and management

• Any capability management (marketing, engineering, UX,

product ownership, etc.)

ORGANIZING CONSTRAINT

Allow edge teams to choose which services from core teams to use. Orient core teams to serve edge teams.

CONTEXT BOUNDARIES

Use context boundaries to define subsets of an overall organization, identifying discrete parts — for instance, all the teams under a single line of business. Context boundaries may have outer core teams dedicated to supporting that context boundary.

As you go through the process of defining teams and missions at the edge and various inner and outer cores, use context boundaries to define larger structures. Some of these structures will be mandated as being part of your organization’s enterprise; some of these will be structures that are defined as you facilitate organizing for agility.

Context boundaries can fall into familiar categories from smaller to larger, paying attention to Dunbar’s numbers:

• Mission/program (i.e., an Agile ecosystem)

• Business unit

• Business portfolio

• Enterprise

ORGANIZING CONSTRAINT:

Avoid edge teams handing work to support teams in the core; encourage people in core teams to travel to edge teams to collaborate on the work.

Chapter 11: Organizing Patterns to Collaborate at Scale

Let’s reimagine our support structure, the people in the core of our organization, in a way that is much more conducive to scaling and supporting Agile teams in an enterprise setting. We can start by populating teams in both the edge and core of our organization, using one of the team-type patterns mentioned below:

• Agile team: exactly what it sounds like, a stable, selforganizing, cross-functional, market-facing team

• Enablement core: a team of enablers who are focused on increasing capability and safety in the organization

• Traveler pool: a team of people that are poised to travel to work closely with other teams in a specific expertise

• Service center: a team in which team members work within their own team to deliver value at the request of another team or internal stakeholder

• Community of practice: a group focused on sharing knowledge and experience, one that is based on employee contribution and grassroots voluntary activity

A simple way of thinking about these patterns in the context of the edge and the core is that edge teams are primarily made up of Agile teams and ecosystems of Agile teams. The core is primarily made up of teams of enablers, with some traveler pools and a few service centers. Of course, this is not a hard-and-fast rule. Your ecosystems on the edge can and will have a mixture of team pattern types, and your core will have a unique mixture of enablement cores, traveler pools, or service centers depending on their stage in the Agile journey.

THE TRAVELER POOL

Travelers contained in traveler pools help minimize handoffs and encourage people to move to the work, rather than moving work to people

A traveler pool is a dedicated group of people with similar capabilities who spend the majority of their time traveling to various Agile teams to provide assistance. This dedicated pool is made up of traveling team workers. Traveler pools allow you to minimize handoffs in the face of demand that does not lend itself to stable teams. Good examples where I have seen traveler pools do well is with dedicated UX professionals, customer research and analytics, and larger program-level UAT expertise.

THE ENABLEMENT CORE

Enablers from the enablement core are dedicated to providing capability to team members; they can pair, mob, or otherwise collaborate with the team to facilitate the transfer of a skill set

Enablers are dedicated to providing capability to team members. At scale we can consider providing a home base for similarly skilled enablers, known as an enablement core. Enablers spend only a little of their time with other core members. They are often assigned to watch over a closely related set of teams, perhaps one or two ecosystems’ worth of teams.

An example would be the recruitment and hiring function in HR. In a traditional organization, many teams would be mandated to go through an HR representative to perform the initial screening, set pay bands, write job descriptions, and engage with talent firms. In contrast, when acting as an enabler, HR would provide a platform to make this job easier for teams. Outside of some minimal rules to ensure compliance with laws and avoidance of reputational risk, HR would not mandate its involvement in hiring. The enabler focus puts the team being enabled in the position of being a customer of HR, as opposed to a team subservient to HR.

TRAVELING VERSUS ENABLING

Strictly speaking, a traveler pool is set up to make it easy for individuals to move to a team to do work in a highly collaborative way with members of the team they are traveling to: by pairing, mobbing, and so on. Likewise, enablement cores are set up to provide a home base for people to move to teams to advise, educate, coach, and sometimes validate work. This can be a somewhat nebulous and even artificial distinction.

As travelers start to engage with the same teams over and over again, those team members can start picking up the traveler’s skills. It starts to make sense for the traveler team worker to take a different stance: that of an enabler. They can pair, mob, or otherwise collaborate with the team to facilitate the transfer of a skill set. As capability sharing starts to happen, the traveler is able to shift their approach and they move away from doing the work to guiding someone else on how to do the work.

THE SERVICE CENTER

A service provider pattern, harnessed within service centers, is often best used when requests are straightforward and when it doesn’t make sense to negotiate a more hands-on, collaborative solution.

Unlike the enabler and the traveler, the service provider works within the service center with other service providers that have similar capabilities and does not work closely with the team requesting their services. Service centers are often about cost reduction; they are cost centers.

This only works when work is considered to be highly repeatable and does not vary greatly from request to request. In these cases, economies of scale can be applied to share demand, reduce cost, and increase efficiency. Service centers handle requests using an approach that involves a discrete request to a provider and then waiting for a response, typically using some form of order ticketing mechanism. A work ticket is placed on a queue by a requesting team, and a service provider working in the service center picks the ticket up off the queue, performs the work required, and then moves on to the next ticket.

In general, you want to avoid using service centers to complete complex work if you want to avoid rework and reduced efficiency. Most back-office functions are organized into service centers. They should not be. The majority of functions provided by HR, legal, compliance, security, IT, and so on would be an order of magnitude more effective if they were set up as enablement cores or, at a minimum, traveler pools.

SERVICE CENTER FROM THE OUTSIDE/ AGILE ON THE INSIDE

A team may seem like a service center from the perspective of the customer team making the request. The servicing team provides a common service using a request-response approach to the rest of the organization. Internally the team also appears to be composed of dedicated team members. They are cross-functional, self-organizing members of what appears to be a classic Agile team.

Most Agile teams in IT departments fall into this category. But all too frequently we see few to no team members having direct market contact; work comes to them from various organizational stakeholders or market proxy roles instead. While the team may exhibit great internal agility, it is very challenging for them to exhibit great market agility. The IT Agile team, like other service centers that are tasked with complex market-oriented work, tries to make up for this lack of market contact through highly collaborative and frequent shaping and review sessions with their organizational stakeholders. For many organizations, this service center from the outside/Agile on the inside approach is a solid step forward.

COMMUNITY OF PRACTICE

A community of practice (CoP) is best thought of as a connected network of individuals who benefit by collaborating on a shared capability or common set of skills or methods. A CoP is often thought of as virtual grouping, one where membership comes from interested contributors from other teams. The purpose of a CoP overlaps with that of enablement cores. CoPs rely on learning through consensus and grassroots involvement. A CoP may have some small funding and an extremely small staff to foster the management of the community, such as running community events or operating an area for the community to share knowledge. But unlike enablement cores, the majority of the work is a result of the community, from people who are actively applying their knowledge in the field.

All in all, the enablement core, traveler pool, and service center all possess the principle of choice. When Team A relies on the decisions made and takes instruction from Team B, then that makes Team B a monopolist, which is an anti-pattern.

Chapter 12: The Blade and the Handle

Many Agile transformations get stuck, whereby surrounding functions, centralized groups, and so on aren’t participating in structural change. The result is an Agile bubble surrounded by a legacy organization. Adopting team-level Agile practices can only take us so far if we want to deal with these issues. To make progress, we need to reexamine our structure and organize around an entirely different set of principles.

PUSHING PAST THE INERTIA FACING SYSTEMATIC CHANGES

We can make progress toward a more Agile organizing structure at the team, ecosystem, or any level by intensifying the conversation around increasing market precision and strengthening value-creation activities in the face of constant change.

But changing toward a decentralized, market-driven organization requires a significant shift in mindset for many who have grown up in a more traditional organization. We often encounter a mixture of concern and skepticism. To truly change our organizing structure, we need to fight inertia and resistance from defenders of the status quo. There are various change methods and change tools you can use to facilitate this discussion. But don’t let any change framework fool you: shifting mindsets and attitudes won’t happen unless you can present a compelling narrative. Good change approaches help structure that narrative, but the hard work is still yours.

A METAPHOR FOR AGILITY: THE BLADE AND THE HANDLE

Using a kitchen knife for inspiration, we can think of improving agility as the act of sharpening our edge and increasing the effectiveness of our handle on value-creation activities.

Sharpening the edge requires that we explore and make improvements related to meaningfulness of purpose, market contact, market access, and our product and business ownership capability.Increasing effectiveness of the handle requires we explore and make improvements to meaningfulness of work, autonomy and independence, our enterprise experience, and delivery and operational capability.

Teams do this by examining their permissions, accountabilities, capabilities, and collaborations with the rest of the organization to understand what barriers can be removed and how best to remove them. While solutions to these problems are often context specific, the barriers to a dull blade and a poor handle are often common.

A Dull Blade

• Poor market contact: Teams do not work directly with customers to understand their needs.

• Limited market access: Teams do not have direct access to market actors and only engage with proxies and/or must seek permission from other groups in order to work with real users.

• Lack of meaningful purpose: Team purpose is unclear or is not motivating; purpose may be viewed as inauthentic, an exercise in propaganda.

• Missing business and product capability: Teams are missing the skills and experience to navigate their market and own their product.

A Poor Handle

• Poor enterprise experience (EnX): Enterprise support functions and governance groups provide teams with a poor experience. Mandatory services and mercurial governance are forced on teams, regardless of quality or value.

• Lack of autonomy and independence: Teams do not have the autonomy to own value-creation activities. Teams must hand off work and are governed by numerous other teams, groups, or departments.

• Lack of meaningful work: Work doesn’t require people to learn and grow. Work is mundane or frustrating.

• Missing delivery and operational capability: Teams are missing the skills and experience to deliver and operate their product.

GETTING THE DIALOGUE STARTED

The simplest way to introduce this frame on existing Agile teams is to bring a list of open-ended questions to the team that help articulate where a dull edge and a poor handle are impeding them. Here are some starter questions, but, again, tailor what you ask to your needs and context.

The Blade

• How precisely can your team navigate the market to deliver value in the face of turbulence and change? In other words, how sharp is the blade of your team?

• Is the purpose of the team clear and well understood? Does your team feel like it has a purpose that is authentic? Is your team’s purpose reflected in the choices, actions, and decisions taken by the team as well as stakeholders and leaders?

• Does your team have direct and frequent access to real users and other market actors? How many other groups are you required to coordinate with or seek permission from in order to work closely with real users?

• How does your team gather feedback from your users? How many users do you gather feedback from? How often does feedback result in a change in the team’s direction?

• Does your team feel it has the skills and experiences it requires to work with market actors and other stakeholders to shape, prioritize, guide, and validate the creation of value? Is your team able to easily acquire, as needed, new skills required to own their product?

The Handle

• How effectively can your team sustainably own value creation in the face of constant uncertainty? In other words, how effective is the team’s handle?

• How often does the team do the work that it loves to do versus the work it dislikes? How often are there opportunities for the team to solve complex problems?

• How much autonomy does your team have to plan, build, manage, and own? How easy is it for your team to closely collaborate with the team it depends on to deliver value?

• How many other groups, departments, or teams must your team hand off work to in order to create customer value? How closely connected is your team to the teams it depends on?

• What are the support groups your teams are forced to use, and which support groups can the team choose to use or not use?

• How would your team members describe the customer experience when dealing with these support groups?

SCALING OUT THE DISCUSSION

It can also be useful to get a wider perspective on the structural impediments facing a large number of teams, perhaps across one or more ecosystems. Surveys can complement workshops to synthesize input from a larger audience, which is important if we want to demonstrate that we have the buy-in for larger changes.

LEAN CHANGE

The approach to improving organizational agility discussed above is an example of how to approach change in an open way. It represents the idea of change co-creation, introducing change in small iterations, and validating the change frequently. These are principles of what I call the lean change method. In a nutshell, lean change asks you to:

● Co-create your change with all stakeholders being impacted by the change.

● Validate your change by introducing change in small increments.

In short, the exact technique is less important than following an open and inclusive approach to change that allows us to introduce incremental changes that we can validate quickly and iterate on if necessary.

Chapter 13: The Software Organization

Because of the pervasiveness of software systems in modern organizations, no serious book on organizational design can be considered complete without a real look at the synergistic effects that organizational design and software system architecture have on each other.

THE PERIL OF IGNORING CONWAY’S LAW

Way back in 1960, Mel Conway observed that when separate groups in a larger organization worked together on larger systems, they would tend to break up the systems they were working on into parts so that each group could work on their own piece as independently as possible. Or to quote Conway:

“Any organization that designs a system will inevitably produce a design whose structure is a copy of the organization’s communication structure.”

When Mel came up with this law, he defined a system more broadly than just software systems, but it is in the world of software that Conway’s Law has gained real prominence. Conway’s Law has been ignored by many an enterprise, resulting in monolithic and fragmented systems that have frozen organizations’ ability to deliver value quickly.

For instance, if you leave the organizational design in the hands of your HR department, then HR will also (accidentally) decide your software architecture. You want the opposite to occur: you want your architects, senior developers, or whatever you call your people with deep software system knowledge to intentionally define teams around the software architecture you have or want to have. This approach dubbed the “Inverse Conway Maneuver” by Skelton and Pais, is an intentional act of reconfiguring the team intercommunication according to the boundaries we want between the different parts of our systems.

The idea here is to use the synergy between the system and the organization “to our strategic advantage. If we want to discourage certain kinds of designs . . . we can reshape the organization to avoid this.”

THE PERILS OF FOCUSING ON SOFTWARE INTERNALS

Historically, we have seen an emphasis on focusing software architecture on system internals, decoupling the technology layers as much as possible in an attempt to create a layered, or “tiered,” architecture. Systems were divided into a minimum of three loosely coupled layers: the presentation, business logic, and data layers. In an attempt to follow Conway’s Law, we would create separate teams to develop and possibly maintain the distinct software for each specific layer of the system.

Systems were divided into a minimum of three loosely coupled layers: the presentation, business logic, and data layers. Often additional integration, orchestration, or workflow layers were added to the mix. In an attempt to follow Conway’s Law, we would create separate teams to develop and possibly maintain the distinct software for each specific layer of the system. Members from all three teams will need to closely communicate to make sure that the changes that take place across the system are consistent and do not contradict each other.

In contrast, when we ask the teams to make changes to how the solution manages product inventory, we would want that change to have low to little impact on adjacent functions, such as how we manage customers or perform billing. But in our current organizational design, concepts such as customers, billing, and inventory are all worked on by the same teams. Whether intentional or not, we are more likely to have chatty interfaces and poor partitioning across these functions, and unforeseen dependencies between these concepts are likely.

INTRODUCING DOMAIN-DRIVEN DESIGN

Domain-driven design asks us to design software solutions that intimately reflect business domain concepts and domain language, according to how domain experts think and speak about the business domain.

Domain-driven design (DDD for short) is based on the idea that the structure of our software systems should reflect the way business experts think about their business. Software should mirror business concepts and subjects, business activities, business states, and business rules. Infrastructural and cross-cutting concerns should be treated as they are, which is as system internals.

Domain-driven design tackles solution complexity because it focuses on the areas of the system that are most subject to change — in other words, the business domains. It places emphasis on capturing the knowledge that is most likely to require experts outside of the field of software.

A team is participating in domain-driven design when they model, communicate, and develop according to the core business-domain logic of a solution and do so using a common domain language, known as a ubiquitous language. Software specialists work intimately with domain experts to capture the domain model, using domain terms, and embed the domain terminology into their code.

ORGANIZING AROUND DOMAINS

If we accept that structuring our system architecture according to business domains is the preferred approach, then we can in turn start thinking about structuring teams according to discrete domain aggregates. A domain aggregate can be thought of as a set of domain concepts that are very tightly interrelated with each other. It can be a customer and their demographics or a shopping cart and all of the independent order items in it.

In larger systems, we place our domain aggregates into separate bounded contexts. A bounded context places a hard boundary around a domain aggregate, or possibly a small number of highly dependent domain aggregates. In a nutshell, we define bounded contexts according to distinct but possibly related domains of knowledge. A bounded context could be set up around a payments domain aggregate, a customer, accounts and agreements, or charging and billing.

Bounded contexts can nest, with larger ones representing entire systems and a smaller one representing a single domain service. We may then refine our bounded contexts by grouping smaller domain aggregates into larger composite domains and dividing larger domains into separate but related component domains. We can structure teams around each bounded context, allowing multiple teams to work in a reasonably autonomous way on a single system.

Partitioning systems into domain aggregates and bounded contexts allows us to define parts of the system that change together and that are naturally decoupled from the remainder of the system, as opposed to partitioning the system based on technology internals, which results in system parts that are highly dependent on each other.

LIMITING DOMAIN COMPLEXITY PER TEAM

A natural question to ask is how much domain complexity a team can handle. Skelton and Pais discuss using domain complexity as a guide to determine this number. I would amend their guidance to include both complexity and degree of change, to determine the number of domains a team can work on at a time:

• One complex domain or one domain undergoing a high degree of change

• Two to three simple domains, or one domain going through two or three simple changes

• Avoid a single team owning more than one complicated domain or having to make substantial changes to more than one domain at a time.

THE MODERN WORLD OF MICROSERVICES

A modern software stack using microservices, containerization, No-Sql, event streaming, and so on enables teams to increase their ability to work within a bounded context while minimizing the impact to other teams working within a separate bounded context.

As mentioned previously, the thinking behind structuring teams so they can develop distinct and decoupled bounded contexts has had an influence on the direction and adoption of new architectural paradigms like container-based provisioning, microservices, and No-Sql. Using modern development and deployment technologies, we can take each one of our bounded contexts and portray it as a cohesive codebase that is represented through a well-formed API and deployed independently from the rest of the system using container-based technology. We deploy a separate container for each bounded context, and each container includes the business logic, data access code, and even the database itself.

When we guide the use of these more modern delivery technologies with domain-driven design and the Inverse Conway Maneuver, we end up with a system that is decoupled in a way that allows teams to work independently and intelligently on a larger system. We avoid the dangers of the monolith and the dependency magnet.

WHEN WE NEED TO ORGANIZE AROUND TECHNOLOGY INSTEAD

While I have emphasized the importance of taking a business domain–based approach to partitioning systems and defining different bounded contexts, there are situations where bounded contexts should be based on technology considerations. This is often necessary when a solution relies on a number of packaged software and integrating legacy systems. In these cases, teams are forced to work with system representations of various domains, and these representations will vary from system to system, hence the need to define bounded contexts from a systems perspective. Delivery flow will be considerably different across systems, with changes involving older technology being rather slow because of more manual testing, onerous deployments, poor documentation, and aging codebases.

So, when working on legacy systems and package software solutions, the diversity in technology may require us to set up teams and their bounded contexts around these systems instead of domain-based bounded contexts.

Conclusion

The key message I would like readers to take from this is that organizing at scale does not have to equate to the factory model of work. We can look to alternative models pioneered by more-modern organizations. If you remember nothing else from this book, remember the following principles:

1. Organize Around Teams

Key to designing the new organization is the idea that teams matter more than departments. Teams that are cross-functional, self-managing, capable and empowered enough to achieve real outcomes, with the right support structures in place.

2. Organize Through Markets

When you want to scale the concept of teams across your enterprise, avoid mandated centralized services and bureaucracy. Instead, connect teams through markets by placing people in direct contact with customers and making use of enterprise services for market-facing teams, avoiding command-side decision-making.

3. Organize for Change

Teams need stability and organizational structure to achieve market outcomes, but this is not always possible in a continuously changing market and market outcomes. We need to equip knowledge workers to adapt to the changes and empower them with the understanding to form teams that create value and eliminate handoffs so that people don’t have to cross organizational boundaries to deliver value.

4. Organize Around Social and Domain Boundaries

Teams of five to eight are often the golden rule, but scaling with agility requires social density at larger scales. Dunbar’s numbers and domain-driven design can be used to group people according to different social outcomes (5, 15, 35, 150). For technology-driven businesses, we will take a page from domain-driven design and align our organization and solution architecture according to domains that can be delivered and managed by independent, full-stack teams.

Challenge yourself to move the needle on these principles and bring others into the discussion. The tides of time are on our side, so be a force for change.