Before We Get Started

Before facilitating an Organizing For Agility workshop it's important to lay down a few ground rules.

Invite Everyone

First try to involve as many people who are impacted by the change as you can. Emphasis on invite, the last thing you want is a room full of non participants. So make sure attendance is voluntary, make it clear that if someone does show up that they will be expected to participate. Don't worry if you involve too many people, for this type of exercise it is easy for people to self organize into groups that are focused on the parts of the organization that they are involved with (or want to be involved with).

Start From The Outside and Move Inward

When facilitating this type of exercise it's generally better to start from the outside and move inward. If market players are unclear start by defining them. Then move inward by understanding what identifying elements are in place for the organization. Then spend some time to establish some context boundaries including missions and outcomes for teams. It's better to start defining teams at the Edge, then defining Core team from the context of how to serve Edge teams. It is usually not a good idea to start from the core and move outward to edge teams.

Use Sticky Notes and Whiteboards to Facilitate the Conversation

The agilists in the room will say "no kidding". For the rest of us this is better if stated explicitly. We want to maximize the use of informal tools and we don't want the design formally specified in a static document. It’ s important to stress that the org design you come up with is not set in stone. The one thing we can expect when working in uncertain times is that we can expect will change. So your org design need to change to accommodate this. The good thing is one people get used to it, refining your org and team structure starts to become relatively painless, but don’t let the need for formal documentation get in the way.

We want to facilitate our workshop in a way that allows all participants to collaborate, and not have one person do the writing. So facilitator, give everyone sticky notes and sharpies, explicitly ask everyone present everyone to physically get involved, get them in front of a whiteboard or 3M style poster boards and get started!

1 - Identify Active Market Actors

It's often good to get started by brainstorming all the external participants that can help achieve our organizational goals, examples include customers, buyers, partners, external marketing agencies, regulators etc. At a minimum you want to just post every market participant you can think of, and start clustering them based on their needs and wants.

Personas

You can also explicitly map needs and wants to each market participant. I have seen teams take a second and third pass on clarifying market participants, this time creating personas for each market participant. Personas are valuable when identifying our market participants because they help us align on:

• customer characteristics and expectations
• Customer needs and wants
• Expected customer behavior

The Spice framework is a nice, concise way to go about defining personas

In short, personas help us make better informed decisions that will inform our organizational design.

Proto Personas

A proto-persona is a good tool to quickly articulate a persona, think of it as an informal, high level description that is easy to create and easy to update. Use poster paper, whiteboards, and sticky notes to get proto personas out quickly.

2 - Define Identifying Goals

As you identify Market Actors, you will want to start clustering them according to Organizational Goals that align with each of these Actors. Start mapping Goals to Market Actors and de-compose these Goals into finer grained Sub-Goals until you have a set of tangible outcomes that you feel could be tackled by a Mission and / or a small number of teams.

As part of this exercise it is often helpful to refine your Goals into the beginnings of an agile style backlog. In effect you start identifying some potential Epics, Features, Minimal Viable Products, etc that Edge teams and/or Missions could deliver to your Market Actors, and then you start doing some initial analysis to get a sense of their delivery priority.

Relative Backlog Sizing and Agile Long Term Planning

Depending on how well your participants knows your organizational goals and organizational demand, it may be beneficial to go a level deeper and further refine your backlog in order to facilitate a better understanding of the backlog for various Missions and their Teams. This allows you to make sure you base your organizational design on the value your Organization is planning to provide to market participants now, and on the value that is next in the queue. If you are facilitating an organizational design session and it appears that organizational priorities are unclear or conflicting you will likely need to step back and start building a backlog that contains larger increments of value you can start allocating to various Missions and teams.

Relative Estimating Done Quick

The first step to creating a backlog, one that provides a better understanding of value and impact, 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. It then becomes easy to assign a estimate to backlog items based on where they are in the stack.

We can use this relative stack ranking approach to size both the size/effort and the value / impact to the market we think it will have. This makes it easier to start prioritizing our demand, putting urgency on work that has higher relative value and lower relative complexity. Note this is not the end of estimating, but a quick way to do just enough discovery to define some reasonable mission and team structure

Using Story Throughput to Get An Understanding Of What is Up Next

As teams become more accustomed to delivering value using Agile methods, they often further break work into smaller increments known as Stories, and they start to track how many Stories they can deliver in a small period of time, typically a couple of weeks or a month in duratio. Many Agilists love to call this period of time a Sprint.

Once teams understand their story throughput (also known as sprint velocity) it becomes much easier to make informed decisions about when the next increment of value will make it's way to our existing missions and teams, giving us a signal that it might be time to revisit our Organizational Design.

Getting Better Backlog Clarity Through Story Mapping

If Goals , Sub-Goals, Epics, Features, MVPs etc 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 that starts at Personas and their top level User Goals (known as Epics in agile speak), then moving to lower level User Actions and Steps, all the way down to micro units of value that can be delivered quickly by teams, ie Stories.

Story maps also allow you define independently releasable thin slices of value, or MVPs. This helps you prioritize small units of value that you can release to your customer. If you are churning on trying to understand the what, the why or the how of an increment of value, I highly recommend you try out story mapping.

Establishing the Tactical Aspects of your Organizational Identity

If you don't feel participants In your workshop have a good handle on their Organizational Identity. I recommend taking a step back and spending some time on articulating Organizational Identity. There are many tools that can be used to help with this exercise. The goal of using these tools is to:

• Understand who our customers are, and what problems we are trying to solve for them
• Agree on the solution we can provide to customers to solve their problems
• Identify the key skills and tasks required to deliver that solution to our customers
• Articulate any key assumptions that should be validated

Some good tools are your disposal include:

• Business Model Canvas
• Lean Startup Canvas
• Journey Mapping
• Impact Mapping
• Service Blueprint
• Cost Of Delay Estimation

Articulating Your Identifying Culture

The tools mentioned above are focused on defining the tangible aspects of an Organization’s Identity, this is important, but it is equally important to align on culture as well. Taking the time to at describe an aspirational culture, ie the Organization we want to be can seem to some to be superfluous, but can really set the stage as the Organization continues to grow. Some methods to describe an Organization’s culture include:

• A Letter To Ourselves
• Values and Beliefs
• Mission Statements
• Culture Document

3 - Map Capabilities and Define Edge Teams and Missions

As you identify an ordered backlog that can guide your organizational design, take the time to list capabilities, skills, and/or roles required to deliver on this backlog. Spend some time to do a high level estimate for each capability you identify. Estimates can be very high level using T-Shirt sizing or some other relative ranking system. As the capabilities become clearer you will be able to cluster similar increments of value together to form missions and teams within those missions. This clustering could happen at the Goal, Sub-Goal, Epics, Feature or whatever level of granularity allows you to have enough critical mass to put teams and missions together.

As you are doing this you can start approximating the number of people you require for a particular capability in specific Edge Team or Mission. At this point it is important for me to stress that this workshop can’t be facilitated in a linear way, you will need to revisit how you are thinking about mapping participants to your backlog and supporting missions as you go.

Take care not to create structure focused primarily on systems, capabilities, or roles. Create teams and mission level structure around Market oriented Goals, Epics, or MVPs if you can.

Refining your Edge Team Structure Using Kanban

As we are designing Edge teams, we may want to get a better understanding of the work that those edge teams will do. This will allow us to make more informed decisions when trying to create context boundaries around teams and higher level missions.

Kanban is an excellent method that not only enables teams to operational their value creation activities with agility, its a great mechanism to further refine your Mission and Team level structure. With Kanban, our effort to Organize for agility can be informed by cataloging market demand to Edge Teams into customer oriented services. Each of these services can them be mapped to one or more discrete work types (capabilities) which is then defined by an explicit and visual flow of work. Kanban is then used to visualize this flow of work in such a way as to spot bottlenecks and other impediments. This provides a rich set of observations that empower teams to continuously experiment on changes that further refine how we are organizing around value. I’ll go deeper into how Kanban informs how we get organized in further chapters.

4 - Define Core Goals and Supporting Core Teams and Missions

As you define Edge Missions and Teams you will likely want to move some capabilities into teams that can focus on common, shared concerns. These are what Core Teams, and Core missions are for. When designing Core organizing structures, you use the exact same process that you would follow when designing Organizing structures for the Edge. In this cased you use Edge Teams and Missions as the Market Participants for your Core Teams and Missions. Use the the needs and wants of Edge teams to define Goals for your Core. You can then map skills/roles to your Core Goals, and further define and refine Core Teams and Core Missions. Of course defining your Edge and Core will be an iterative process, you dont need to finish figuring out your Edge before getting started on putting up some Core items as well.

Inner and Outer Cores

Likely you are working in a larger enterprise that contains capabilities and services that you are mandated / highly encouraged to use, they just come with the package of working in your enterprise. In these cases it is helpful to model these services as coming from on or more Inner cores. Examples of inner cores include Enterprise level services and managed Business Unit level capabilities. Neither are likely to be far along the Agile journey, but you may be surprised.

When working in this context all services that you are able to facilitate change with can be placed in your organization's Outer Cores. Services that are provided to a small number of teams, perhaps in a single mission can be though of as belonging to the outer most core. Services that are provided to a larger number of missions, a whole program, a portfolio of work, or a whole business unit can be thought as belonging to Cores that are closer and closer to the center, ie they are progressive more inner cores.

A Special Note On Context Boundaries

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 organizations enterprise, some of these will be structures that are defined as you facilitate organizing for agility.

Context Boundaries follow the same narrow to broader categorization that cores do, in fact all wider context Boundaries will have a minimum of one core team, the team responsible for managing that Context Boundary. Typically there will be other core teams allocated to the Core zone defined by the wider context boundary, or else there is little justification in the existence if the Boundary. Again context Boundaries can fall into familiar categories from smaller to larger:

• Mission
• Program
• Business Unit
• Business Portfolio
• Enterprise