The term Scaled Agile has emerged because Agile has traditionally been implemented as a grass roots movement across the IT industry on a team by team basis and not on an organisational level.
Very bright developers and their immediate managers came up with Agile and then development teams have brought in and implemented the methodology in their workplace.
Agile did not start its life as a corporate set of instructions from the top down.
As Agile has grown in popularity, organisations have found themselves with a lot of Agile teams and no real way to plan large projects which involve multiple teams.
In its nature, Agile varies scope and keeps costs and time fixed. If you have 100 teams, all producing a variable functionality scope, how do you manage the integration across these teams into a large enterprise system?
There have been several attempts at addressing this and the forerunner is the Scaled Agile Framework from Dean Leffingwell. SAFe uses Scrum/XP at the Team level and builds on it to provide additional guidance for Agile at the programme and Portfolio level.
He and his colleagues implemented this at Symbian and then Nokia across several hundred teams. I had the privilege of working with one of the business managers who hired Dean on a project at Aircom International.
I was also trained by David Hicks from Agil8 who worked with Dean at Symbian.
There are other approaches to scaling agile which whilst not as popular as SAFe are at least worth being aware of:
- DA – Disciplined Agile
- LeSS – Large Scale Scrum
We will cover the SAFe framework here as this has the most potential to become the dominant scaled agile approach.
What is Scaled Agile?
Dean has reviewed several different popular Agile methodologies and taken all of the things that scale and built those into the framework and also identified those that do not scale and has offered solutions to mitigate these or suggest other ways in which the same benefits can be achieved.
According to the website:
The aim of Scaled Agile is an interactive knowledge base for implementing agile practices at enterprise scale.
The Agile methodologies that are heavily referenced are:
- Extreme Programming
- Scrum
- Kanban
- Lean
The big picture
The big picture is a term used to describe the one page slide with encapsulates the Scaled Agile Framework. It forms the home page of the Scaled Agile Framework website. The picture on the website is fully interactive and you can drill into any part of it to learn more.
Why do you need to know about it?
More and more organisations are taking on the Agile way of running software development and therefore the need to scale Agile methodologies is now what most software producing organisations are facing.
Most financial organisations are going through this transition with some resisting longer than others. BNP Paribas has moved to a top down Lean software approach across the entire bank whilst NYSE are still struggling to deliver simple projects with their waterfall approach. Most financial organisations are somewhere in between.
This page is required reading for the manager role and the architect role. Good Agile Managers are increasingly needed to understand how they can deliver products which span across multiple teams and Scaled Agile gives Managers and Architects that tool kit.
How can you learn more?
You can read Dean’s book “Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise (Agile Software Development)”
And you can also attend a two day training course and become a certified SAFe Agilist. I strongly recommend you take the Scrum Master Course and have a good grounding in Scrum, Lean and Extreme Programming before taking the course.
You can also visit the Scaled Agile website, however, I have found this hard to learn directly from and is useful more as a reference.
Pre-requisites
As you are scaling agile across the organisation, you need to have a good grounding in the methodologies you are scaling. For this reason, you should have a good knowledge of Scrum, XP, Lean and a bit of knowledge of KanBan before taking on SAFe.
What scales from the common practices?
Many of the practices from other methodologies naturally scale. These practices can then be implemented across any number of teams. The list of practices that scale are given by Dean in his book as:
- Define / Build / Test Component Team
At a very high level, this is treating the process of Define – Build – Test as a building block at each level of the planning, like a unit of a fractal diagram, this block can be used at each scale of the product lifecycle. Cross functional teams are also a scalable concept that work well across the organisation. - Two levels of planning and tracking
This is a two level planning process, the larger level defines the release and the more detailed level is at the iteration scope. This gives a longer road map view at the release level. A release is made up of a fixed number of iterations. Iteration planning occurs just before the iteration at the last responsible moment. Scope remains variable depending on developer progress and other factors affecting what is being delivered that is only discovered during the development cycles. - Mastering the Iteration
The iteration is at the heart of the Agile process and this scales well across multiple teams. I have found it important to keep the iterations the same duration and start times across teams as this makes planning much easier. The downside of this approach is if you have to have people in multiple iteration meetings on different teams as they will inevitably be held at more or less at the same time. - Smaller, more frequent releases
Small releases give quicker feedback and provide more data for velocity planning. This works well on many teams as well as one team. - Concurrent testing
Testing at the same time as writing code scales well across the teams. - Continuous Integration
Continuous integration is another area that provides immediate or at least very quick feedback ensuring the different parts of the system work well together. Continuous integration is arguably more important the larger the system is and the more teams that work on the overall product.The environment needs to make this work may get more complex but is still scalable with modern repositories such as Mercurial or Git. For further reading I recommend reading about Multi-stage Continuous Integration (MSCI). - Regular reflection and adaption
The three pillars of Agile: Transparency, Inspection and Adaption also scale well. This can scale both at the development team level and throughout all level of the organisation.
What doesn’t scale automatically and how to make it scale
Not all aspects of Agile scale well when multiplying up the teams and looking at the organisational level. The Scaled Agile Framework offers the following solutions to concepts which work well at the single team level but not at the multi-team level:
- Intentional Architecture
At the team level, Agile practice recommends that architecture emerges from the stories in a just in time basis. Architects sit with the team and work on the stories at the same time or slightly ahead of developers. The overall architecture emerges as stories are complete. However, at scale with lots of teams, this approach does not work on an organisational level. Intentional architecture addresses this by developing high level designs at the release cycle and low level designs in the usual way. The high level designs keep all the teams on track and the individual teams still allow their architecture to emerge whilst keeping in line with the governance of the high level design. Another approach to allow easier integration across teams is to define the interfaces up front and share amongst the teams. This allows early integration even if it is against mocked interfaces. - Lean Requirements at Scale
In different Agile frameworks, requirements are dealt with differently. In Scrum and XP it is recommended not to use the term requirement and to use the term story instead. Managing a large number of stories is difficult and no longer simply summarizes the product.For large scale requirement / story management, the Scaled Agile framework borrows ideas from Lean and Unified Rational Process and recommends the following artefacts:- The vision document
- The road map
- Just in time elaboration of stories
- Agile Release Train
The release train is defined as the releases given across many teams and how to organize them into a cohesive project including integration of the separate releases. - Distributed Teams
The Agile Principles behind the Manifesto include the following:“Business people and developers must work together daily throughout the project.”And“The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”In most organisations of any size, teams are not located together and in some cases members of teams are not even in the same time zones. There are several resources that advise on how to manage these scenarios in an Agile environment.In Dean’s book, he gives several case studies about how other teams have managed this problem. These include making sure stand-ups still happen even if they are on the phone or using some other tool, re-organizing teams both around components and geographical locations and visiting regularly.There is also some more guidance from Mike Cohn’s book ‘Succeeding with Agile’ in the chapter ‘Distributed teams’.
Learn more and get certified!
Learn more about extending agile across the enterprise on our highly-impactful and certified agile training courses in London and online.