Achieving system optimisation goals in LeSS
Large-Scale Scrum(LeSS) has incorporated deep Systems Thinking ideas in its recommendations. Whether it’s the way Sprint Review is done or the recommendations around team co-ordination, LeSS recommends system optimisation over local.
In this short post, I would like to share two system optimization goals in LeSS out of many.
- Organizational design to deliver the highest business value
Traditional organizations have many layers of management with multiple siloed groups turning their machinery as fast as possible. As we all know, this siloed way of working results in local optimization.
To avoid local optimisation in the context of org design, LeSS recommends:
- Building team-based organizations through dedicated, cross-functional, long-lived teams
- Feature teams over component teams
The organizational structure itself is recommended to be lean with no functional organisations like a QA department, a release management or a deployment group. Teams are encouraged to work directly with each other without any intermediaries.
Agility could be defined as the ability for the organisation to turn on a dime for a dime. It is also the ability to change the course or direction with low cost and friction. See Continuous Improvement Towards Perfection for more.
To keep the post crisp, I will focus on a single backlog vs separate team backlogs.
In LeSS teams pick items from the one prioritized backlog rather than having separate team backlogs. You might be wondering, how can separate backlogs hinder agility as teams will be more so-called efficient if they can work independently? The answer is, having a separate backlog not only makes each team to be deeply specialized in one area, but also results in losing the focus on the overall priority. At the end, single specialisation is a bigger problem than becoming multi-skilled as a team.
The actual trouble with multiple backlogs starts when the organisation wants to change the priorities. Due to the nature of single specialisation created due to separate backlogs, the teams won’t be able to turn around quickly and learn new skills thus hindering agility.
The solution is to encourage building T-shaped “teams” and avoid allocating the items upfront to specific teams. Teams should get involved in multi-team PBR reducing the implicit backlog dynamics thus increasing agility and avoiding local optimization.