I was asked by a Product Owner to come and have a look at one of his teams. I served him getting Scrum going about 1,5 years ago and he wanted to know how they were doing now. When I asked him what he wanted me to do exactly, he smiled and said he wanted me to "shake things up a bit". (This article builds upon a basic understanding of Org Topologies™).
Since I worked with the team, they had grown from five to eight team members. They work in a complex and large corporate environment. The original idea 1,5 years ago was to create an autonomous team working on a feature set (A3), but I observed now they were spending most of their time managing dependencies (A2). After observing some of their events and a session to make an inventory of the main problems they experienced, we scheduled a "ready for the future" session. The goal of this session was two-fold: 1) Explore possibilities for creating more in-team cohesion between the product specialists and the developers and 2) Understand how the team might best cope with the existing (inter-team) dependencies.
Introducing the Org Topologies™ Map
To kick off the session, I introduced the team to Organizational Topologies™ (OT™). We explored the organizational archetypes on the map and tried to determine where the team is now. We concluded that over the past 1,5 years, the team had grown from their initial Y0 (individualistic task-driven work) via A1 (a team of product specialists without developers) to A2, an incomplete team with a feature focus. It took about thirty minutes to explain the OT™ tool. The team could then identify their journey and current position. While assessing their journey the team was using a common language while talking about organizational design: the language of Organizational Archetypes.
Exploring the journey on the horizontal axis
We then zoomed in on the horizontal axis of the Org Topology™ map. This axis describes the in-team collaboration and focuses on the capabilities needed to deliver a working product in the hands of the customer. We need to focus on how autonomously the team can create a final product, in other words, we study the team's dependencies.
A good question to get clarity on the dependencies is: What skills does the team need to be able to deliver "DONE" autonomously, i.e. from idea to production? Someone on the team replied: "There are so many skills needed that we will end up with a team that is way too large!". I suggested that we should make this concrete by summing up all those skills. They came up with about 15 skills.
With the capabilities listed, we need to understand how this impacts the functioning of the team. We marked which of these capabilities were currently not present in the team. Since we do not want to implement solutions to resolve exceptional situations, we only want to focus on the most important missing skills. Important here means: occurring most of the time. For every missing skill, I asked the team to think back and determine if they needed this skill in seven of the last ten sprints, i.e. do we need this skill (capability) 70% of the time? If not, then this is not a very blocking missing skill. (I prefer to pull up the Product Backlog history for this to prevent generalizations, but in this case with the PO present, that was not necessary). We ended up with 5 capabilities that were missing and frequently blocking: Requirements analysis, Test specialism, Branding, "TP-application"-skills, and Legal.
To reduce the list, I asked the team if there were skills that would no longer be important in the (near) future. The "TP-application" was to be decommissioned later this year. The team agreed to deal with this dependency for the time being and understood further investment was not a wise thing to do.
To tackle the final list of four, I asked the team if they had any proposals to resolve the remaining skills.
The developers proposed to find an analyst and a test specialist and add them to the team. The Product Owner mentioned that this was an expensive option. The other team members were arguing that anybody could learn analysis and testing and that actually existing team members doing this work would be a better option because this would keep the team nimble. Then the developers were arguing that T-shaping would reduce their specialism. The Product Specialists on the team observed that they had learned a lot from each other's expertise over the past time and this had turned them into specialists with multiple skills instead of reducing their primary specialism. We also agreed that the company offers guilds and chapters to specialists to keep their knowledge up to par.
Often, when Product Specialists create new offerings or change existing product conditions, there might be legal consequences. For example, relaxing loan conditions could turn a loan product potentially into a liability for the bank. Team members agreed it would be interesting but not feasible to do a legal study to cover all legal matters. Instead, the option of having someone in close proximity, ready to join the team in refinements is good enough. Someone argued that in many cases, Legal was asked prematurely and that it would be worthwhile to define from what level legal advice is indispensable. They would make agreements with legal so the team would get the mandate to decide by themselves when they need legal support and when not.
In summary, the team came up with the following generic options to solve the missing skills problems:
Existing team members learn the skill (acquire knowledge)
Agreeing with stakeholders to give the mandate to the team (acquire permissions)
Automate and create a self-service solution (no-code/low-code solutions)
Having someone close to the team who can help refine and provide feedback
Adding someone with the missing skill/knowledge to the team
An appropriate solution was found for each of the missing skills. The team was surprised that there were so many other achievable options other than the obvious, adding people to the team.
What about the vertical axis?
The vertical axis describes how collaboration takes place between teams. The team had grown from tasks to features (Y to A level) over time. When studying the OT™ map, they concluded they had now arrived at the B level, working as a Business value area. This was incorrect, they were still at the A level working as a single team, because there was no team of teams. I wanted to make them understand where they are now and what it takes to work at the B level. (Having clarity on your current position and knowing your destination is important when you are on a journey).
We drew the teams in circles on a whiteboard in a larger circle with the department name and around all a circle with the name of the company.
We then asked ourselves the following questions:
How often do we coordinate work with the other teams within our department?
How often do we coordinate work with other teams outside our department?
What is the name of the product that each team in our department is responsible for?
And: Is the customer willing to pay money for "our product"?
Now what does the customer perceive as being the product? The team agreed that this would be the combined output of all teams working in the department: A business loan. For example, if the customer does not want to pay for the registration of their customer data, the customer does not want to pay separately for getting a new loan and for making a change to an existing loan.
With that product definition in mind, we explored what would be "the best team" to serve the customer. Or in other words, what product knowledge should our team have so that it can independently deliver all customer value? The answer is: each team should have the product knowledge of all current teams combined. I drew this picture to explain the feature team concept:
Just as becoming T-shaped makes team members more adaptive on the horizontal axis (skills), broadening product knowledge makes teams more adaptive across the vertical axis (breadth of product understanding). Making this change creates groups, "teams of teams", in what we in Org Topologies™ call "Business Value Areas". These groups are able to absorb much more variations because they span a greater area of knowledge. This move would require teams to be reorganized and product backlogs to be aggregated to contain true customer value items.
Team members wondered what could be possible reasons why you would want this aggregation and reshuffling of teams and they wondered if it would apply in their context. We came up with the following benefits:
If we consolidate, we have fewer dependencies
There is much more connection between product work and software development work (and there will be less local optimization)
Capacity problems in the current teams are solved when we combine teams
We can work much more efficiently because we all know what we are going to make, and also because we are working on the same goal at the same time
We will deliver more valuable products to customers
We discussed some concerns (and found answers to most of them):
This is quite a drastic change. Can we do this? Do we need approval?
What will the Product Owners think of this?
How will this affect the surrounding service teams we work for?
How do we divide run and change work?
How do we maintain knowledge of our specialisms?
How do Sprints work with so many people at once?
The objection that was mentioned last "that it could be very difficult to work in Sprints with such a large group (about 60 people)" was something I paid some extra attention to. I explained how this is usually done in LeSS with Multi-team Backlog Refinements, joint Sprint Planning, and Sprint Reviews. You might want to read some more on how to facilitate these large-scale events here:
Another interesting question was, "If we don't make such a deep change, can we nonetheless benefit from the perks like the higher B and C levels do?" The answer to this is: Yes, you can! The effect will be smaller, but it will help you "get used" to that way of working. For example, by starting with a joint Sprint Review, you will make it easier for stakeholders to join an event where condensed information can be acquired. And at the same time, you will find that retrieving feedback on the result from the combined teams is more rewarding than from each of the teams individually. This provides an incentive to look for ways to work together more intensively.
Conclusion
This team now has an understanding of the downsides of their current team setup. They have been studying their history and current position from a systemic point of view. They have assessed possible future states and understand what moving up to the B level on the Org Topology™ map could bring them. They also already see what this will require of them and they have some idea of how this B-level with a team of teams might work.
In only 1,5 hours the team has taken the first important step toward taking ownership of their organizational design.
© 2022 Roland Flemm and Alexey Krivitsky for Org Topologies™.
