I recently published a video exploring how an agile team based organization could look like. How does it function under the hood? In the video I also discussed how you get there.
I got tons of great feedback so I decided to provide the contents of the video in the format of a blog. If you prefer to read instead of watching a 11-minute-long video, then this is for you 🙂
If you prefer to watch the video, here it is. If not, scroll down and continue reading.
.
The traditional top-down hierarchical organization
I would like to start with a comparison to a traditional top down hierarchical organization. The following is of course an over simplification, but let this pyramid symbolize the organization.
A traditional top-down hierarchical organization
Let’s start with all the people that do actual value adding work. They constitute the foundation of the pyramid. They create products and provide services to customers and users. They are the craftsmen transforming ideas to something that can be delivered, that is useful and of value for our users and customers, which eventually brings us profit and growth.
.
The few at the top
At the top of the pyramid we have a small group of people in charge of the company who are responsible for the overall success. They live under the strong belief that
“For us to be successful we need to be able to make smart decisions and be in control”.
It’s a hard job, but that’s what we’ve been hired to do. Besides, how could possible the individual worker have a good enough overview perspective to make smart decisions. Besides we can’t have everyone running their own show in different directions, right?
So, for us to be successful we provide structure, guidance and focus to our workers by making tough decisions and enforcing policies and processes.
To help the few at the top to reach everyone and to manage all the work, we have managers and middle-managers. Through budgets the managers are delegated power and influence.
By imposing deadlines and only providing information on a need-to-know basis the organization ensures that people are focused on the projects they are working on without being distracted. Deadlines also give us means to follow up on progress and costs.
For the few in charge to be able to make smart decisions they continuously gather status reports and collect data. To achieve and maintain control they demand clear paths of accountability. And for them to quickly get insight into how things are progressing reports, processes and tools are standardized.
There might be thousands of people in the organization, but the need of the few drives standardization, even where it is neither needed nor helpful for the people doing the actual work. To maintain control a lot of bureaucracy is often introduces. The need to quickly understand progress and status also drives simplification and abstraction.
.
The risk of simplification and abstraction
For a few to understand and control something as complex as an organisation, the information needs to be simplified and abstracted.
But reducing reports to one-liners, project progress to green/yellow/red, and adding more manager layers to reduce the number of interactions creates even more distance between the few and reality.
This results in decisions not anchored in reality, nor solving real problems.
Insights into real problems and opportunities become obscured by this simplification and abstraction of information.
.
Structures grow and solidify
If the organization has been on this path for a couple of decades you will have created an organization with structure and processes that makes life easier for the few at the top.
You will not end up with an organization that is adopted for helping great people do great work and achieving great results.
The structures that the managers reside within tend to grow a life of their own and solidify. Some research claim with as much as 11% per year.
The process and bureaucracy was probably added to solve a problem but the structures with its people tend to grow a life of its own and solidify, even though the problem was solved long ago.
.
How does an agile team based organisation differ?
In an agile organization, we have the same great people. We have all those doing actual value adding work, but instead of being spread thin, staffed into projects governed by budgets, they organize themselves in teams.
The teams are long lived. Their work might vary over time, but the work is always aligned with their mission. A mission could be to cater for the needs of a specific market or user group, develop and maintain a product, provide an internal service and so on.
An agile team-based organisation
Properties of an agile team
An agile team has a couple of properties.
Cross-functional – The team is cross-functional, which means that the members together have all the competences necessary to execute on their mission, to transform an idea into something that can be delivered to their customers.
Co-located – An agile team is co-located, the members of the team physically sit together to maximize collaboration and communication.
100% – Members are fully dedicated to the team 100%, no other competing commitments.
Stable – Agile teams are stable. It takes time for a team to become strong and high performing. Frequently shuffling people around undermines this.
Autonomous – An agile team is autonomous. They decide together how they want to work, how to solve problems, who works with whom and in which order work is done. Within the boundaries of their mission, they need to figure out the best strategy to reach their goals.
Owns process and quality – They own and shape their own processes and they have a collective responsibility for the quality of the products and services they deliver.
.
Guidance and support from top managers
We also have the few at the top, responsible for the overall success. In an agile organisation with an agile culture and mind-set these people however believe that
“For the teams to succeed they need us to provide clear guidance and support.”
Each team governs themselves and make decisions on a daily basis. For them to be able to do this they need to know what the overall vision is so that they can align their own plan to the overarching goals. What are the top priorities? What are our top challenges?
To make good decisions without resorting to gut feelings and chance, teams need access to information and context. This is usually achieved through transparency.
To be able to resolve their own problems, people and teams are given empowerment and trust – trust in that they want to do a great job, are doing their best and that they approach work and problems responsibly.
.
Support when teams request it
The managers and middle-manager’s job is to support the teams with all of this. They are there to help the teams be successful.
They provide feedback and guidance when teams request it. It could be feedback on deliverables, or guidance when they have multiple options in their roadmap.
When a team can’t resolve an impediment because it’s beyond their area of influence, they request help.
.
Managers provide support
When they need support, they turn to the managers. Teams might request all kind of support.
Tools – It could be approval to purchase new system or invest in tools.
Environment – It could be work environment related. New chairs, whiteboards, noise cancellation carpets, or maybe plants to make the team room nicer.
Training – Perhaps they have learned that they need training to be able to tackle the next challenge.
Protection – Sometimes they might even ask for protection, help keeping greedy stakeholders or disturbing intruders away so that they can focus on what’s important.
.
Managers help teams establish dialog
Teams will also ask for help to establish dialog with other people. They might ask for help to get connected to other teams that they are depending on. Quite often they need help getting hold on stakeholders to understand their needs. Establish a dialog between customers and users is also vital for the team to get feedback on deliverables. Relationships with external partners can sometimes be tricky and complicated.
.
Close active leadership
This is however only the start. An agile organisation takes a couple of more steps. In an agile organization, the managers and middle-managers don’t reside on a separate floor. They are not disconnected from the teams.
In an agile org, managers work and live close to the teams
To be able to provide support and close active leadership, they live and work among the teams. To understand the needs of the teams they sit next to them and listen in on meetings and discussions.
Furthermore, the top managers don’t regard themselves as being on top, governing everyone beneath them. They also provide support, but in a different shape. They work with improving the overall health of the system and providing clear guidance on priorities.
.
Teams have end-to-end responsibility
For a team to do a truly great job, we don’t stop here. As I’ve already stated, each team is responsible for figuring out how to best execute on their mission, and are held responsible for quality end-to-end.
Because of this we make sure to connect the team with their customers and users so that they truly can understand their needs and pains.
And end-to-end responsibility also entails that the teams deliver to whatever platform or client those customers and users are using.
Agile teams have end-to-end responsibility
.
Rapid learning and feedback loops
To enable rapid learning, we invest in establishing feedback loops. We want to learn quickly if the things we build are of high quality, if automated tests fail when we make changes, and if we are progressing fast enough or if we need to reduce scope.
We also make sure to continuously learn what the users think about the product. Is it solving their problem? Are we reaching the desired impact? If not, we rethink and reprioritise.
.
Agile organizations at scale
The example so far has depicted a company with three teams. What if we have 50 teams? How does it scale?
Big agile team based organisations, as any big company, are divided into organizational units, such as departments or similar entities. Each department tend to be smaller than 150 people. However, departments aren’t split by competence, or systems. The teams stay intact.
Common strategies are to group teams that belong to the same value streams, or work in the same product family, in one department. Another strategy is to group teams that have the most dependencies between each other together.
.
Alignment on long-term strategies
Even if we have autonomous teams that rapidly deliver value to our customers, we still need to align and agree upon a couple of long term strategies. If everyone runs in their own direction we soon end up in undesirable state with a lot of confusion, conflicts, and incoherent product strategies.
One approach to deal with this is to create forums. One forum could discuss and decide upon long term architecture strategy. Another forum might work on improving the joint delivery process. One forum could have decision power regarding long term work environment and seating questions.
Each forum consists of elected representatives from each team, as well as manager representatives, ensuring that all perspectives are included in the dialog. The forums have mandate to decide within their area. If you want to influence a long-term strategy, you engage in that forum.
Alignment on long-term strategies through forums
.
Cross-team sharing and sync
Finally, not only do agile teams learn through short and frequent feedback loops, they also need to learn from each other as well as synchronise plans with other teams.
For example, the java developers probably meet frequently in something called a Community of Practice to learn from each other, to share knowledge and experience.
Two or more teams might be working on the same project for a limited set of time, thus introducing the need for synchronisation and collaboration.
Perhaps there is a group of people responsible for the long-term health of a development framework. They would get together to plan and discuss upcoming work.
Cross-team sharing, planning and coordination
Wrap-up
Replacing bureaucracy and slow processes with autonomous fast teams doesn’t come for free. The oil that makes the engine run is communication – lots of communication.
With that said, I now wrap up this introduction to how an agile organisation could be structured.
I hope this article answered some questions and managed to bring clarity to how it works under the hood, and a glimpse of the journey on how to get there.
I like a lot of the comments made but the knowledge of a complexity based systems of work is woeful. Agile as described here has a lot in common with our Requisite Enterprise and Sociocracy. The view of the hierarchy here is straight out of a 1960 text book sadly.
Your view on a Agile organisation is a welcome addition to the body of knowledge, but is not revolutionary or requires any significant review of what is known to work. A lot of it sounds like sociocracy (holocracy evolved from it).
What it does require some is new integrative thinking which I think many would welcome, especially those who are caught in the cross fire of matrix, agile, lean, hierarchy, muddles, not to mention those leading them.
Thank you Andrew for your feedback and thoughts!
I agree with you that the simplified description I made of a traditional hierarchical organisation were more common in the 1960’s, but I sadly know they are still some around. I’ve worked with a few of them. I included my description of the “pyramid” in order to make it easier for myself to explain a summarized explanation of how an agile org could look like and function. And yes, parts of the agile thinking with regards to teams and distributed ownership can be find in Sociocracy.
I guess the search for strategies and approaches to address the needs and challenges of large scale agile team-based organizations happens all around us as we speak. My wish is that more people would share what they learn. I bet there are examples of new integrative thinking and other great learnings out there waiting to be shared with the community.
Great summary. The one question I have is how to organisations ensure that business critical functions are actually done by fully autonomous teams? This is the another significant driver bureaucratic processes (other than the need for the few at the top).
Hi Bruce! Happy to hear that you liked the article.
Not sure I fully understood your questions, please clarify if I misunderstood you.
Since most teams deliver on a regular frequent cadance, have frequent retrospectives, and have leadership and managers working closely with the team to support them, it very quickly becomes evident if there is a people or competence bottleneck in a team responsible for business critical features/services. Furthermore, teams are very rarely in an environment where the can be “fully” automous. Even though the collaboratively figures out how to solve problems and who does what, they still need to align on priorities with other teams and departments. I’ve seen this done in many different ways: through OKRs, Big Room Planning meetings, Product Owner hierarcies or Product Owner teams, Company Backlogs & Roadmaps, etc. Most agile companies I’ve worked with believes that’s impossible to “ensure” things like this up-front through organizational design. It’s something you learn through work, communication, measuring, evaluating and retrospectives.