Imagine that you've been asked to help somebody re-organize their business from scratch. They want maximize their agility, and group people into self organizing teams. Now imagine that we have open slate when it comes to determining the upcoming goals for the business and the value that each teams will provide has been left largely undecided, save for a few overarching mission statements. You have been asked to help an organization come up with their backlog from scratch while figuring out a team structure that could best deliver on that backlog. Your mandate is to help leaders come up with a new structure that deliberately breaks down the functional silos that currently exist, and come up with a network of cross functional teams spanning tech, operations, marketing, data, and product development. By the way this is a large financial service organization.This is the exact problem that Tyler Motherwell and I faced a few months ago, so Tyler and I worked together on this post to share the approach we used to tackle the problem.
In brief we followed a five step approach (don't you know you can do anything in five easy steps).We followed a highly collaborative barnraising style, where we had an initial kickoff with leaders in the organization followed by weekly sessions where we refined our design. We then ran an all hands session to provide everyone with a chance to iterate on what was put together by the leaders, and then proceeded to stand up team level backlogs and Kanban systems.
- Domain clustering the medium term (3-6mnths) goals for organization; Identifying common themes and synergy
- Impact mapping each domain in order to get a better understanding of initiatives and the behaviours that we are looking to change in our stakeholders
- Draw boundaries on the impact map to define team mapping to specific impacts and analyze the skills required to deliver potential initiatives
- Cluster related initiatives, unexplored domains, and operational processes creating team definitions
- Determine how teams will interact and service demand using our Agile Ecosystem Design toolkit
The power in taking this approach is that we were able to pull people from what they were used to in terms of existing organizational structure. When you really want to initiate change, it can useful to start with tools that support blue sky thinking ( ie impact mapping).Domain ClusteringDomain Clustering was just a way for the coaches to get alignment with the various teams on how important business concepts could be grouped together according to how similar the involved work was. We wanted to take an approach that was as low fidelity as possible so that leaders could swarm on different concepts and imagine all the possible things that could fit in the overall universe of the business they were in.We would also annotate each domain cluster with some of the key ways to measure the impact of working on a domain. The result was a rich set of subjects and master subjects that we grouped into potential teams.
Impact MappingNext, the leadership team took a divide and conquer approach, taking a specific domain each, and refining the domain concepts using impact mapping. Each group defined a set of measurable goals contained within the domain that would form the basis of creating the impact map. The group then brainstormed the various personas and behaviors that would help that team achieve a particular goal or set of goals. Epics, features, and MVPs were explored that could realize the behaviors on the map.
Deliverables and goals were then analyzed for over arching business metrics, typically attached to the goals on the impact map, as well as leading indicator metrics that were attached to the deliverables on the map. The deliverables were then estimated at a very high level and placed into an overall backlog.
To recap, each cluster in the domain is impact mapped using the following steps:
- Define the Mission and Outcomes: Identify clear, measurable goals for the business to achieve. Break up into Outcomes and Sub-Outcomes
- Identify Personas: Brainstorm all the stakeholders, sponsors, and users that can help achieve that goal, examples include customers, operators, sales, marketing agencies, etc
- Define the Impacts: Ask how can each person identified can help to achieve the goal in the form of altered behaviors exhibited
- Surface Features: Brainstorm the ways that the business can achieve the impacts required for each persona to achieve the objective. Decompose larger Epics into smaller Features / MVPs to increase clarity
Over a couple of weeks each group held separate sessions to come up with separate impact maps, after which everyone together and reconciled the maps , in effect showing the universe of impact that this business wanted to achieve.
Team MappingWe then took a look at the impact maps and started to define team boundaries. The idea here was to allocate a certain portion of the overall impact map to a potential team. The boundary could be dawn around any level of the map, from higher level goals, to sub goals, behaviors, or deliverable. Once a team boundary was drawn up, it was analyzed for the kinds of skill sets/capabilities required to realize that area of the impact map. This was an iterative process, with different boundaries being drawn, and redrawn based on getting a better understanding of what skill sets could be combined into an effective, and reasonably long-lived team that could solve organizational goals.
When assigning capabilities within a a certain team boundary, we took a look at the amount of commitment required for that individual capability, a simple high/medium/low rating. We also took a page out of Domain Driven Designs' bounded context map and specified whether the team would be best served if that capability was provided using a shared kernel pattern, i.e. the work needed to be done within the team in a highly collaborative way, or whether a customer supplier relationship would suffice, where work could be done by sending it from one team to another.
Team DefinitionWe next ran a set of sessions focused on making our abstract team model a little more real. We took each team identified in the impact map and started slotting any current work or upcoming work to it. We categorize this work into large “change the business” style Epics, process work, and “business as usual” type activities. We then mapped this work to the capabilities in the team, and finally assigned real people into the various teams. This of course was also an iterative process which caused us to challenge some of our assumptions that went into mapping impacts to teams.
We added the metrics from our impact map onto the top of each team's definition. At this point leaders were ready to "officially" socialize the various team structures across the organization. Of course unofficial socialization had been happening throughout the process given that the models were created and displayed in a highly accessible place and we welcomed anyone to come by and ask questions at any time.As we started understanding the relationship between demand and capabilities, we defined the customers for each team, whether that be another team or an external customer, as well as the reusable services that could be provided to those customers.
This analysis facilitated different teams abilities to start standing up Kanban style visual management systems based on providing customers with value based on specific services.
Ecosystem DesignAt this point the organization was ready to stand up teams, and start adopting various Agile Behaviors. More practically speaking, this involved providing basic agile training, helping teams stand up backlogs, design Kanban systems, and put a set of event cadences in place.In parallel we asked teams to start thinking about how they would best interact with each other and teams within other areas of the business, designing a kind of value network, where nodes in the network were different teams.
Our coaching team has previously created the Agile Ecosystem Design Toolkit primarily for the purpose of assembling value networks based on agile teams. The toolkit provides a variety of service delivery patterns and team linking patterns.Service Delivery Patterns describe a particular way an agile team can serve as a customer.
Team Linking Patterns describe different ways agile teams can interact with each other. We created these patterns by looking at a variety of popular agile methods, as well as our experience in what we've seen work when deploying agile at scale.
As the various teams become better acquainted with how agile works, they are in a better position to start looking at their overall system of work and laying out the best way to move people to different teams taking advantage of the various service delivers patterns. Often we have a large ecosystem design session where a large number of folks can collaborate together to coming up the best team network model. In this instance, we are only starting to look at these kinds of patterns. Stay tuned for more details as this progresses.
