Visually Managing Flow of Value Across The Ecosystem of Teams
Using Long Term Planning with a Graduated, Visible Backlog is just the beginning in terms of how we can scale organizational agility to help a collection of self organizing teams become an ecosystem Of self-forming teams , as the complexity of our ecosystem increases, we can look to using Visual Flow Management with Kanban to enrich our team members understanding of the work, it's value, where things are getting stuck, and where to help out.
Read more in my book on Agile Organizational Design
A bit on why Kanban is a nice way to scale out classic agile style visualization
There are many descriptions of Kanban out there that do a much better job of what Kanban is and why it can be so valuable to knowledge workers who need to collaborate in the face of constant change. In stead of repeating much of what has been said elsewhere, I though I would discuss how Kanban can help agile teams take organizing behaviors to the next level, one based on end to end value, and interacting with other people both within and outside of their team.
Let's start by describing your stereo-typical agile card wall. Here we can see stories that are broken up into tasks, with tasks going through a fairly simple flow. Once all the tasks are done we can mark the parent story as done as well.
The problem with this form of visualization is that it can get very cluttered, very quickly. If were to look at an ecosystem worth of work, we would have a swamp of information, and our visualization would not be giving us the information we needed to help people organize outside a very small scale. Not great for organizational agility.
What is interesting to note is that most of the information used in this type of visualization is noise, ie the tasks. Notice how the vast majority of tasks on the board are the same, I have witnessed this to be true for the vast majority of teams (we will talk about exception later). At some point writing these tasks out start to make you feel like a child being punished for talking in class.
Let's look at the Kanban approach to visualizing this work. Tasks are ordered according to the team's agreement of a reasonable workflow. The team collaborates to write out a set of knowledge worker agreements (Policies in Kanban speak) to create a common understanding of the work to be typically done in each state, and even the people that may take the lead in that state. Note that we expect that this flow and the accompanying work agreements are expected to change, and we expect it to change constantly! The idea is not set rules in stone, rather it is to give the team a lightweight way to continually update how they would like to flow their work.
It will be arguable to some about which form of visualization is better at the team level. Where a Kanban style of visualization starts to really shine is when you start thinking about scaling your visualization to encompass a larger portion of value creation activities.
Scaling Horizontally
Kanban can be used to scale horizontally, connecting teams to other knowledge workers who may typically work upstream and downstream of them as part of the flow of value creation.
By encouraging multiple teams, stakeholders, and other participants to collaborate in front of this style of visualization, they can start engaging with each other as if they are part of a common ecosystem, or even a common team, regardless of the "official" organizational structure. We can encourage participation in common outcomes and we can better align and engage across a wider horizon of activities.
Scaling Vertically
Kanban also allows us to scale our visual management vertically, to encompass multiple teams, an entire Agile Ecosystem, or even a larger unit of the organization. Often with this style of visualization we abstract the work each team is doing to a higher level than individual stories, for example outcomes, or thin slices. Even though this level of abstraction is less accurate, it is often enough detail to facilitate understanding of where our organizing structures are not serving us well, and where failures in collaboration are impeding value creation.
Using Kanban To Continuously Re-Organize Around Value
Using Kanban makes it much easier for people to understand the end to end flow of work, and encourages people to form agreements that allow for a kind of grass roots self-governance to take place. We get a common understanding of people's starting position within the flow of the work, and more importantly, we can also get a sense of how people move into new positions to collaborate with others. (Remember the Hockey Maturity Model metaphor?) We can start thinking about value networks not as hand offs across teams, but as concentric circles, with people overlapping to ensure work flows smoothly.
Kanban is working especially well when people are able to transcend any official team structure or hierarchy to swarm around a problem that is impacting the flow of value. I have seen this work especially well in Kanban system at multiple flight levels. ( a term borrowed from Klaus Leopold)
Kanban can enable Dynamic Re-Teaming Across an Agile Ecosystem, increasing Organizational Agility
I have had especially good experiences helping others use Kanban at the team of teams level, what I am again, referring to as an Agile Ecosystem. Using Kanban at the ecosystem (others call it a program, or a portfolio, or a tribe) level allows people, people who may or may not be dedicated to a "home" team, to organize not only across the flow of value creation, but also help across departments, teams, or other "official org structure".
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. People start to transition their thinking from static structure (team or otherwise) to a set of organic interactions that promote flow.
Use Visualization to Illustrate Capabilities and Expertise in more Detail
Simple flags and other annotations can be used to articulate what capabilities we need to complete a piece of work, and what capabilities are in possession of a team within an ecosystem. This snapshot was taken from a Kanban System used to facilitate a large scale regulatory program that consisted of more than 11 teams. At the beginning of the program, high level story mapping was used to understand what product and system experts were needed across more than seven different organizational departments.
Team were quickly assembled by color coding each expertise required for the program, and then assigning that color to Epics in a prioritized program level backlog. People were also color coded according to the expertise they were contributing to the program. Here we can see the people belonging to two different teams represented on the Kanban, right next to the Epics that the teams were working on.
During this program, team composition and number of teams flexed based on the work flowing through the system. Some team members were more or less fixed to a team, while others acted more as travelers, and would shift across teams frequently, in some cases daily. A subset of senior people played more of an enabler role, using the Kanban to assess what teams could use their help. The process of people moving across teams started as a manager led one, but over time it became the responsibility of everyone working on the program. Planning, stand up, and review cadences were used to create a common awareness of how to organize around the value, people moved across the teams accordingly.
There all kinds of creative ways people can choose to illustrate the capabilities required to complete a piece of work, as well as the capabilities present in an ecosystem. In an attempt to increase people's ability to organize around the value, I have seen clever use of annotations, and team and even individual "hockey cards" with simple icons to indicate various skill sets.
This kind of visualization of capabilities on your Kanban system, can be taken a touch to far, especially if by the off chance geeks are involved in designing your Kanban system, so take care not to let this get out of hand. :)
Remember the point of visualizing capability is to make it easier for people self -form into the right structure that will allow for the creation of value with as few hand offs as possible!
There are limitless ways people can self-form around value, but I have seen some patterns as well. I will go over these in an upcoming chapter on Dynamic - Teaming patterns.
There are also different ways we can encourage people to attend to this kind of visualization at the Ecosystem level. I will discuss this as part of my next post on Cadences aimed at Multiple Levels of Feedback.
Read more in my book on Agile Organizational Design
