Optimize your organizational structure for agility.
Wolfgang Steffens (kai kaku Oy).
Abstract. This report is based on my experiences across 3 different companies from the insurance and automation industry.
In all of the cases, I was called as an Agile Coach into those organizations after management had decided their organization needs to become “agile”. Prior to the decision, all organizations had conducted a Scrum pilot with 1-2 teams which did not contribute to the main product of the organization. The work they did was somewhat isolated and so the one-team Scrum approach was well fitted. Those pilots demonstrated improved productivity and even some kind of adaptiveness when it came to responding to changing requirements. Thus, management decided in those cases to move forward and copy-paste Scrum to the entire organization ranging between 120-450 developers. In all cases, management decided critical parts of the organizational structure like team scope, PO-team relationship, and team backlogs.
Each organization decided to establish cross-functional teams either through self-designing team workshops or by management decision. In all of the cases, the teams were not truly cross-functional as critical skills were missing like architectural skills, testing, Ux, domain knowledge, or deployment. Besides having dependencies between all those component teams, the teams did either have dependencies to underlying database and platform organizations, or to the application layer. In the end, they were all variations of component teams either in form of system components or full-stack teams with narrow domain scope, all with significant dependencies to others.
Management assigned one “Product Owner” per team with those “POs” typically being team leads or sub-project managers in the old set-up. Each “PO” was then, as a team lead before, middlemen taking orders, responsible for coordinating the team’s work with other “POs”, spoon-feeding their teams by writing detailed requirements, doing analysis, and talking to the stakeholders. In one of the cases, we had a set-up with 30 teams and 30 “POs” working all on the same platform which was used by several applications. A real Product Owner focuses on the business, is an entrepreneur, and all those team “POs” were far away from that.
In order to prioritize the work of the team, each of the “Team POs” created a team-specific backlog. Typically those backlogs contained every kind of work except real customer-centric Product Backlog Items covering the requirement end-to-end. In order to complete a customer-centric feature, there was a need to coordinate across multiple team backlogs. Besides the significant coordination effort, the results were that the teams only knew their own very limited area. This silo knowledge hindered the organization to shift direction easily and focus on the highest value items. Instead, teams were kept busy and worked on items of lower value from an organizational point of view. Sometimes, the teams even knew that, and yet they continued to work on low-value items since the organizational structures did not allow them to work on other items.
Those structural elements of team-specific backlogs, “team POs”, the composition of component teams, all together induce a system that is not very adaptive. Changing direction is very hard due to silo knowledge. People are very busy producing output yet less outcome. In this kind of system management adds even more teams, and the productivity goes down even further.
Only in one of the cases, I was able to flip the organization after they had worked several months in the chaotic multi Scrum-team setup. Instead of regarding a single component as the “product” by forming teams around those many narrow products, we defined the one real product from the customer’s point of view. Since there were too many teams to be directed by a single Product Owner, we introduced three customer-centric product areas which were independent of each other. We establish cross-functional, cross-component Feature Teams which could convert a customer-centric PBI into a product increment on their own. Dependencies between teams were minimized and the remaining ones were handled through well-defined APIs. This more modular approach enabled the delivery of well-tested real product increments.
Now the one real Product Owner focused on the long-term and strategic view of the product, and each Area Product Owner focused on her own Product Area, working together with the teams and prioritizing the content of the Area Backlogs. The results were mind-blowing. Besides the boost in morale which was achieved through a self-designing team workshop, in which each person could decide which Product s/he wants to work in, we saw a significantly increased level of collaboration between the teams. Now all the teams were working together to create each Sprint a product increment containing only the highest value items.
In all the cases I have experienced ignorance and lack of knowledge when it comes to the basic understanding of organizational design. Especially critical are managers since they make important decisions on the structures of organizations. None of the managers which I met in those companies had the skill of systems modeling and thus they did not have tools to understand the dynamics in their organization from all the interactions. Instead, managers copy-paste models from other companies, or naively think that copying one-team Scrum to multi Scrum-Team will work. They lack the basic understanding that their environment is complex, that they need to run their own experiments, need to find out through Inspect and Adapt what works in their organization and whatnot.
Keywords: agility, scaling, scrum, organizational design