Thinking organisation structures with Agility
The title may lead you to think that this is to talk about an agile process for thinking about the organisational structure, but the idea here is more like defining an organisational structure that promotes agility, its principles and values, in the construction and delivery of products.
My need to think on the organisation structure is not only a current challenge connected to the growth of the company where I currently work. It is also a topic I was involved previously in a large company with the need to better structure itself in order to be more agile.
In the current case, the growth originates growing pains and doubts regarding how to better evolve and adapt. For an already large structure, it might need to transform itself in order be more adaptable and efficient.
As a first approach to these kind of challenges, we have some known scaling “solutions” that we can adopt. I see agile scaling solutions as frameworks that, when properly applied, can bring improvements. But, there’s always a but… there are also some possible pitfalls that we can work on avoiding them.
I see and love agility as a way to apply frameworks and strategies to a specific context. By knowing the pros and cons of each approach we can work on following the goals towards the pros and work on diminishing the cons.
Thinking on organisations structure, could we just choose and apply a framework?
Let’s go into some of the challenges I’ve been experiencing.
Let’s star with a cliché: No Silver Bullet
Looking into things in the agility umbrella, we have different scaling frameworks to use in our context. LeSS, Scrum of Scrums, Nexus or even SAFe can help on defining a base structure to respond to the organisation growth.
I say “even SAFe” because it’s hard for me to see the SAFe approach as an agile one, but that is a very beaten topic and I will not go into it. Might make sense in some contexts but I prefer to look into other, less overcomplicated and more team and user focused solutions.
I tend to prefer the LeSS approach and its principles. But, for now, it’s a personal opinion based on beliefs and others testimonials.
But applying an agile framework like LeSS, alone, it also have some possible pitfalls when the number of teams in one area raise significantly. Mainly, my concerns are around the possible lack of ownership, focus and specialisation that can raise and be an issue.
The lack of ownership can easily happen when spreading the ownership by several teams and, consequently, by several persons. I noticed in several situations that broader ownership leads to no ownership — we loose the natural sense of having something as “mine”.
Of course I believe in collaboration and we should give space for people to work in a collaborative way. But having people collaborating does not have to mean that everyone will own it. It’s hard to have the sense of ownership when there’s too many people involved.
It is very important to empower ownership and, when the ownership is too spread, people tend to loose that sense of “my product” or “this is the result of my work”. We can use Dunbar’s numbers to understand the effect on group cohesion depending on the number of people involved in it — with a direct impact on the collective ownership feeling. A bit more about this below in this text.
The result of what teams build can also be affected by the number of teams involved in it. When building a product, the product users could also suffer with possible confusing available options, as an effect of having several “feature teams” working on the same product or area. Each team are focused in a specific feature and might loose the connection between features developed by different teams. The communication between teams is key here and the number of teams affects the number of communications channels between them. More communication channels leads to over communication and the inherent waste of time. On the other end, the no usage of those channels, could lead to bad products as people could be building solutions with gaps or overlaps between the parts that each team delivers.
One other aspect that makes me think is the intention on avoiding (over)specialisation. Overspecialisation can really be an issue and bring serious problems over time on the organisation flexibility and adaptability, but some specialisation can be very helpful. Lack of specialisation can result on loosing too much time on starting with something because of the need of gaining and spreading new learnings. It reduces the possibility of having effective internal help for business or technical needs. Finding the balance should be the key.
When some of the points above were trigger problems that lead to a team organisation review, we should take them as starting points towards improvements and think on strategies to solve them.
A strategy: divide to conquer
It’s important to identify focus areas (or domains, or sub products) where teams can really focus on how to improve, not only in terms of business but also technically. And, then, apply a scaling strategy on defined areas, domains or sub products.
Like stated in the LeSS definitions, having more than 8 teams leads directly to a “LeSS Huge” approach. This approach “breaks” the organisation into areas and apply the LeSS approach into these areas (max of 8 teams on each area). I think we can extrapolate the definition of area into “area, domain or sub product”, depending on the context of each organisation.
The point here can be on how to identify those areas, domains or sub products.
While researching for some work or studies that could aid me on some scaling challenges in my teams, I found the definition of “fracture planes” in the Team Topologies book. I like the reasoning behind it and believe we should use it to identify the system areas, domains or sub products in order to:
- Maintain ownership of a part of the system by a group of people that can really work together;
- Guarantee focus in one part of the system, work to improve it and be responsible for it;
- Have the cognitive load manageable, leaving space to solve problems and have innovative ideas.
There’s no one way to know how to split the system the organisation builds, there are some options to look at (Business Domain, Regulatory Compliance, Change Cadence, Team Location, Risk, Performance Isolation, Technology, User Personas…) and we need to look to the context and understand what could make more sense.
And the numbers are important
We should have Dunbar’s numbers in mind to help us. Having a strategy for scaling teams around a product in an effective way must also take in consideration that teams can grow to accommodate demands and there’s a limit for it.
As group grows we should not expect the same level of cohesion between people. This is affected by the exponential growth of the connection between people in the group and the cognitive individual limit to maintain “a stable inter-personal relationship”.
As examples, this is the base for what we know nowadays as the common definition for a team size: from 5 to 9 persons. And, for a bigger number of people working on one same area, we would not have more than 50, if we want that people to have a better “inter-personal relationship” and cohesion level.
As we approach a known limit on the group type, we should work on breaking it, finding the way of splitting it and applying the scaling strategy with each new defined part.
Managing high complexity
Sometimes the amount of knowledge and complexity can be higher than what is sane for a team to handle. This makes the team just to react, not be able to think on how to improve it and bring innovative ideas.
Adding more people to the team will increase the amount of connections and possible waste. Splitting the team into feature teams that work on the same domain will not reduce the complexity each team needs to handle.
In that case, the split can be defined by amount of cognitive load, e.g., things to handle. Instead of just splitting people into smaller groups, the domain should also be redefined in two (or more) domains where a team can handle and own one.
Some reinforcements might be needed to join the divided parts, making them able to develop their new domain autonomously and — I like to reinforce this point — with space for innovation.
So… what’s the point?
I guess it sums up as “yes, it’s complex”. Organisations should be live beings that can adapt to what is needed to produce good outcomes. But building this structure it’s not an easy thing nor there are known easy solutions to make it a success. We just need to consciously look into the challenges, start with one approach that seems to fit better the context and interact in it, in an Agile way.
Finally, some learnings (so far…):
- Should start by evaluating the challenges you have and want to improve — this makes you understand how to inspect and think on how to improve;
- Evaluate possible solutions, try to find practical examples and check what could make sense in your context — what works for others might not work for you, but learning from others experience, in their own context, has an enormous value by avoiding known pitfalls;
- Look for the initial setup with what is a balance for what you know so far — might be the usage of a framework, a mixed solution or even a new thing you believe it makes sense in your context;
- Start with something and adapt based on agile experience and mindset — must keep in mind that the first solution could not be the last one to try or even that the context can change over time and the structure will need to be adapted to it.
If you reach this point, I thank you for reading it. :)
Feel free to comment, agree or disagree! I’ll also learn from it…
