An Approach for Large-Scale Agile Adoption Challenges
In this post I would put my insights on approaching the challenges that exist in large-scale agile adoption. Those insights were generated as part of my final paper in the M.Sc. degree. I hope you would find some of those insights helpful for you as well.
I’m an engineering manager and an internal agile coach at Avaya. I’m practicing Agile since 2014, and in the last 2 years Avaya went through a business agility transformation. Today we have more than 80 teams as part of the agile journey, over 10 locations, developing various products using various technologies (small products, big products, innovative products, legacy products, on-premise, cloud, many teams, few teams, etc). We have developed our own scaled-up agile flavor — AIM (Avaya Innovation Model).
As being part of an agile core team, my colleagues and I have gained a lot of knowledge and experience while coaching and mentoring the teams. However, I was always curious about the academic view on the large-scale agile adoption. Therefore, I have decided to do my final M.Sc. paper about challenges in large-scale agile adoptions. I will start by a short overview about agile frameworks.
The first seeds of agile methods came in the shape of Scrum and XP (eXtreme Programming) in the 1990s. Those methods were targeted for a single team. The focus of those methods was a single team, where the multi-teams case remained “unsolved”. Later, Kanban and LSD (Lean Software Development) were introduced, where the focus was mainly on delivery flow.
I could clearly see that Scrum, XP, LSD and Kanban are used as the foundations for most of the large-scale frameworks. At first the software industry approached those methods as opponents, meaning people either chose one or the other. In time, organizations started to adopt hybrid approaches by using more than a single method. For example, Scrum with Kanban, Scrum with XP, and so forth. Reviewing the methods in depth, I could not find a real conflict between those frameworks, and using combination of those methods makes a lot of sense. Those hybrid methods were adopted and became popular. One great example is the publication of “The Kanban Guide for Scrum Teams” in February 2018, describing the power of using Kanban practices for Scrum teams.
The second wave of methods started around 2010 (e.g. SAFe, LeSS, DAD) and those methods were created to solve the multi-team product case. Apparently, those methods cannot be used together, as each one of them has some conflicting definitions and different roles and events. Nevertheless, organizations may choose to take parameters from various large-scale methods and create their own hybrid method. One great example of that is a company named Spotify that invented its own large-scale method, probably by using ideas from the existing methods and creating its own flavor. While reviewing the academic papers, I couldn’t find any research that indicates that one large-scale method is more effective than the other.
Agile adoption has its challenges on small scale, but the challenges increase dramatically on large scale. A wide range of frameworks are available, which makes it hard to choose one to start with (either in small scale or large scale). The ones I investigated for this purpose are: LeSS, Nexus, Scrum@Scale, SAFe, DAD, Spotify. Regardless of the large-scale framework you choose to start from, it seems all deal with similar challenges while scaling agile.
Practices and Challenges
There are certain agile practices that are recommend for adoption. Those practices are not trivial to achieve, and organizations face challenges in adopting them. I will not get into why those practices are recommended — this is out of the scope of this post (although you can easily find tones of information on each one of those in the internet). The practices I would mention in this section are the main ones I have observed in the academic papers as being challenging for organizations. See below the practices and their challenges:
- Self-organized teams: lack of alignment, command & control approach (as opposed to servant leadership)
- Cross-functional teams: specialized teams, I-shaped engineers (as opposed to T-shape/E-shape engineers), need for code coordination, barriers in code ownership
- Unified backlog: a backlog that is distributed across teams and/or few backlogs per team
- Inter-team coordination: lack of self-organized teams, lack of cross-functional teams, distributed teams
- Feature-oriented backlog: technical work items, big work items, lack of unified backlog
- Continuous planning: knowledge workers not part of planning, lack of prioritization, plan as a contract, lack of inter-team coordination, lack of feature-oriented backlog
- Large-scale testing: lack of automation, lack of CI/CD pipeline, lack of validation each iteration
- Date-driven releases: poor large-scale testing, lack of continuous planning, fixed scope
I won’t drill down into each one of them in this post, but I would mention that while reviewing the academic papers, I have identified dependencies between those practices, and I have tried to reflect those dependencies on a graph (see below). The gray boxes represent the practices organizations seek to achieve and the white boxes represent the challenges that organizations should overcome for achieving those practices.
Looking at the graph above, I could detect 4 layers of dependencies:
- Layer 1: unified backlog, cross-functional team, self-organized team
- Layer 2: feature-oriented backlog, inter-team coordination
- Layer 3: continuous planning, large-scale testing
- Layer 4: date-driven development
This brought me to the conclusion that it would be advisable for organizations to tackle the challenges in that order for having the shortest path to a date-driven releases (or on-demand releases).