Agile Organisation Structure
The move to Agile ways of working is often thwarted by functionally organised teams. In this article we explore what changes are necessary to move to Agile ways of working, and how to do it, avoiding the dreaded big J curve of change.
One of the biggest barriers to Agile adoption is changing the organisation (org) structure to support Agile ways of working. Orgs that are new to Agile are commonly organised by function – IT, Finance, HR, Legal, Operations, etc. Even within IT teams can be organised by sub-function – Business Analysts, Developers, Testers, Architects, UX.
The traditional org structure
The most common structure for pre-Agile orgs is by function as in the org chart above. This is typically how a Waterfall mindset organises itself. So why can’t you retain the hierarchical structure and use Matrix Management to create co-located cross functional teams? Because this approach cuts straight across deep rooted tribalistic instincts putting staff in a very difficult position forcing behaviours such as manipulation, politics and coercion.
Tribalistic traits are most prominent in these circumstances. Tribal traits* are overt in such organisations especially when teams act to secure their self-preservation if their security is under threat – often the threat is Agile with its cross functional co-located teams. When a team lead insists their direct reports sit together in close proximity to the team lead this is the classic tribal trait of a strong tribe has a walled city – a place of refuge where things of value to the tribe are kept. The hardest part of any Agile engagement is getting the ‘Revered figureheads’ to let go of their tribe. They usually act to reinforce their security when under threat from Agile transformation.
Agile org Structure
A fundamental pillar of Agile and Lean is cross-functional teams closely collaborating to produce software. Therefore if you were to produce an Agile org chart it might look something like the example above. In this example we have 3 teams, each responsible for a product (this org has 3 core products) containing all the individuals required to convert ideas into value.
Floating Roles
Not all roles need to be dedicated and ring fenced to the team. The economics often simply don’t add up. A classic example is the UI Designer role. Yes it’s an important role, but you might struggle to keep them busy full time on a team. The availability and movement of staff across teams is called Staff Liquidity.
Advice for moving from Function to Cross Functional team structures
Moving from functional teams to cross functional teams is hard. There are many stresses associated with the transition:
- Team leads / managers will feel threatened “what’s my role in the new world?”
- Individuals within the teams may have established long term relationships with their functional peers – this is about to get torn apart
- Teams may hold old battle scars from past dealings with the other functions – they’re about to get thrown together into cross functional teams!
How to move from Functional to Cross Functional teams
Avoid the big bang change. Avoid the stress. It’s totally unnecessary. Instead follow the Kanban Change Management Principles:
- Start with what you do now
- Understanding current processes, as actually practiced
- Respecting current roles, responsibilities, and job titles
- Gain agreement to pursue improvement through evolutionary change.
- Encourage acts of leadership at all levels
You can bring these principles to life by following our guide to getting started with Kanban.
* reference: Great Boss Dead Boss by Ray Immelman
Portfolio Kanban
Take a deep dive into Portfolio Kanban on our instructor led online course. Take your Kanban game to the next level learning about how Kanban deals with Dependency Management, Risk Management, Portfolio Visualisation, Scheduling and sequencing work across multiple teams at scale, Resource Management and more.
FREE KANBAN CHEAT SHEET
