Like this article? Read more in my book on Agile Organizational Design!

The Need to Constantly Evolve Your Organizing Structures

As I mentioned over the course of my book, if you want to foster organizational structure that increases agility, then you need to organize around your most important outcomes. We don't know up-front what most important outcome is coming next. Sooner or later our team structure is going to be wrong. Eventually, people will be working on the wrong thing, or work will need multiple teams to complete it, creating cross team dependencies, which we hate.

I have seen an nicely designed ecosystem of agile teams, left unchecked, devolve over time into a mess of dependencies in a matter of months. No team could deliver on their own, no team could own any particular outcome. The answer is to continually garden team structure with an eye to adapting the simplest structure to meet the needs of the environment.

The good news is that people with agile experience already have a lot of experience in gardening the way they are organized, they are just more familiar with gardening at a smaller scale than what we are talking about now.

Foundational Agile Team Behaviors Enable Self - Organizing Teams

Continuously organisation is a key part of Agile. Lets look at the day / week in the life of a stereotypical agile team.

This image has an empty alt attribute; its file name is self_organization.png
  • a subset of the team collaborate with stake-holders to shape the work so that it is ready for the team to work on, defining acceptance criteria, fleshing out details, decomposing it. etc
  • Weekly or even daily, the team collaborates to prioritize the next set of work to accomplish, creating a backlog for the team. The team will often divide into smaller groups, to "pair off" against individual items in the backlog
  • The team then meets frequently, perhaps daily, perhaps more often, to agree on how to do the work, pairs are often switched as needed based on availability and capability, knowledge sharing, or pinch hitting to help each other out
  • At the end of the cycle the team reviews what was accomplished with each other and stakeholders, they will take time to reflect on how they could have planned and delivered differently in an attempt to improve the way they work.

Agile Practices That Enable Self Organizing Team

Within a team we see members re-configuring dynamically into twos and threes and fours as necessary to accomplish the team's overall goals. The following agile artifacts and practices help team members continually reorganize to meet the demands of the day

  • Team Planning and Sprint Backlogs allow a team and stakeholders to get organized around the highest priorities
  • Team Stand ups, and Reviews provide a means for team members to reorganize around the work using the latest learning
  • Visual Work Management and Definitions of Done by making it clear how the team wants to work and how they are actually working, this makes it easier to understand team members need help from each other

Armed with these, or similar practices, team members are continuously organizing, and re-organizing how they work together . Team members self-organize in the most effective way that can accomplish the goals of the team.

Scaling Foundational Agile Team Behaviors Enable Ecosystems of Self Forming Teams

The concept of organizing and re-organizing around value is something that scales beyond a single team. Personally I have seen these organizing behaviors scale up to almost 200 people. That being said, it is better with a a smaller group, say 30 - 50 people. This is the number of people that would fit into a medium sized Agile Ecosystem, enough people to deliver value for a product/ product family, customer/market outcomes, or organizational objective. Assuming that the teams within this ecosystem have spent enough time working with the agile concepts mentioned above, than we are ready to scale that behavior out to the overall ecosystem.

This image has an empty alt attribute; its file name is ecosystem-planning-1024x572.png

A day in the life for an ecosystem of teams could look like this

  • ecosystem leadership and team representatives collaborate with each other and stakeholders to prioritize and shape the next set of strategic outcomes to be delivered to the market
  • This group meets monthly, or more frequently to conduct cursory analysis is on these high priority items, enough to understand what team(s) could deliver on it, as well as an order of magnitude effort to deliver
  • Items are placed onto a cross team backlog, based on priority and team delivery capacity to deliver, team structure, including number of teams, team composition, and team size are evaluated and adjusted based on the context of this new demand
  • leadership and other team representatives meet frequently, perhaps once or twice a week, to discuss how the current structure is working, to handle cross team dependencies, discuss any changes in priority, and other issues that could impact multiple teams, at any time team members may elect to travel to other teams or otherwise adjust team structure based on the latest learning
  • At the end of the month or quarter both leaders and representatives from team reviews what outcomes were delivered to the market, and reflect on how on how the ecosystem of teams could have planned and delivered differently

Agile Practices for an Ecosystem of Self Forming Teams

Within an ecosystem, we see members across teams re-configuring dynamically team structures necessary to accomplish the ecosystem's over arching highest priority outcomes. By revising some the team level agile artifacts and practices mentioned above, ecosystem members can continually self - form into teams that achieve outcomes.

In my next set of posts I will go through each one of these practices and go over how to use them to enable dynamic re-teaming at scale.

Like this article? Read more in my book on Agile Organizational Design!