There are many organisational structures out there for agile software development. How should executives think about selecting the right one?
The Organisational Dilemma in IT Software Development
The digital age business environment is characterized by fast pace, global competition, changing customer behaviours and rapid technology shifts.
Companies therefore want their IT applications to be customer centric, innovative, valuable and delivered in a flexible way with fast time-to-market. On the other hand, they also want them to be stable, secure, cost efficient and with market access to resources.
So the question arises: How do you structurally organise your software development for meeting those objectives?
Nine Organisational Structures
Over the last decade most companies performing software development have started or completed the implementation of a new more agile setup. While their setups might look similar from the outside, in reality there are significant structural and semantic differences between the models they choose. In illustration 1 & 2 we have indicated nine models used in practice.
Illustration 1: Organisational structures for software development - key archetypes. Analysis by Oleto Associates.
Illustration 2: Organisational structures for software development - detailed structures & roles. Analysis by Oleto Associates.
The structural models tend to differ on two dimensions: Delivery agility and Planning agility.
Planning agility is the model's ability to enable flexible and iterative planning of what needs to be developed, i.e., the products/solutions and the value they are expected to bring. A model with a high degree of planning agility would allow a rapid reconfiguration of resources to match new priorities. A model with a low degree of planning agility would make it more difficult to realign to shifting priorities.
Delivery agility is the model's ability to enable business centric and iterative implementation of products/solutions needed. A model with a high degree of delivery agility would allow a high degree of autonomy in how work is performed and by whom in the teams. A model with a low degree of delivery agility will have very clear standards and guidelines for how the work is performed and the roles it takes to deliver it.
The nine agile structure models are:
- Department: Hierarchical structure divided into departments based on skills with planning and value evaluation centralised in mid and top management
- Flatarchy: Hybrid between hierarchical structure and flat autonomous teams deployed ad hoc with programme planning centralised at management
- "Amazon" small teams: Hierarchical business and planning organisation, but with small autonomous teams reporting directly to senior management
- Programme: Departments formed around programmes and projects in order to provide more agility within selective value streams
- SAFe®: Small scrum teams working in short iterations coordinated on the portfolio & programme level through release trains
- "Spotify": Similar to SAFe, but emphasises autonomy in choosing between agile methodologies, rather than solely on Scrum
- Product specialist: Organisation of highly skilled professionals coordinated through strict processes, where program tasks are distributed by a small planning team
- Scrum@scale®: Network of scrums coordinated and planned through participation in higher levels of scrums
- Adhocracy: Employees entrusted with full autonomy to self-organise teams, plan their work and choose which direction is most valuable for the company
Additional models are relevant when third parties are involved in the software development, but these are not covered in this perspective.
Selecting the Right Model
Executives faced with the challenge of selecting a future agile model should consider a number of key questions before homing in on a preferred structure:
1. What are the business objectives and drivers, e.g., per BU, customer segment, product?
2. What are the pain points and value leakage in the current model?
3. What are the future implications for planning agility and delivery agility of software, including semantic preferences (how do you name the units/teams/roles so there are easily understood in the wide organisation)?
4. Which structural agile archetypes (and later methodology) is closest to what we want and how do we tailor it to our exact needs?
5. How do we best transition from our current model to the target?
Please note agile methodology, IT operations, cloud and outsourcing aspects are covered in other articles on this website.
If you would like a high resolution copy of Illustration 2 Organisational structures for software development - detailed structures & roles then please contact [email protected]
About the authors: This article was written by a team of consultants from Oleto Associates, a strategy consulting firm based in Denmark. For more information please visit www.oleto.com
July 2024