So you have been working in an Agile team for a while and your team is increasing in size till it does not make sense to keep it as is? Or you plan to work on a large product already with multiple teams? So you are thinking about scaling and having multiple Agile teams working on a product or program…
But you do not know what to choose between Agile scaling frameworks such as Nexus (Scrum.org), Scrum@Scale (Scrum Alliance/ScrumInc.), SAFe (Scaled Agile) or Large Scale Scrum (LeSS)? Or should you just use a Scrum of Scrum? Phew, hard choices to make – huh?
Before looking at any of those above frameworks and techniques (which are similar in many areas actually), one should understand the basic building blocks of scaling Agile. So let’s have a look at what those building blocks are…
First things first
Paraphrasing Bas Vode and Craig Larman (the creators of LeSS) on the first thing to scaling: DON’T! Just don’t do it.
Before any attempt on scaling, have a meticulous view on what is slowing you down in delivering value to your customers and how you can actually improve this delivery – you could use a value stream mapping for example. A key info: the efficiency ratio between one developer to another is said to be 1 to 10 but… the efficiency ratio between the best and the worst development team is 1 to 3000! So here is the thing: do you have the right team in place and are you already doing everything properly?
If you are not doing Agile right at team level, do not expect that it will get better at scale. You will scale problems instead and end up with many headaches. So ensure that you have the basics right before moving on to the next stage.
The kernel of scaling Agile: Scrum
No matter how you try to turn it around, the building block of the most popular Agile scaling frameworks is and will remain: Scrum! That is why we have the term “Scrum” in Large Scale Scrum (LeSS) and Scrum@Scale. Nexus does not have Scrum in its name but it is from the so called House of Scrum (Scrum.org) and although SAFe has (intentionally?) removed most of the references to Scrum in its terminology, nearly every Agile team is doing Scrum while doing SAFe (minus one or two teams on Kanban only…)
So again here: if you do not have your Scrum roles, events, artifacts and rules under control, do not expect that this will get better in scaling. Scrum is the base for all those frameworks so get it right first before scaling!
Ok, I guess that you got the point and you know now that Scrum is the base for scaling. But what does that mean exactly?
Well, it means that when you scale, the Scrum roles, events, artifacts and rules will also be scaled.
Let’s see how that works:
Scaling Scrum Events
So we have 5 official events in Scrum: the Sprint, the Sprint planning, the daily Scrum, the Sprint review and the Sprint retrospective. We should also not forget about the backlog refinement which is not an official event but is extremely handy.
The Sprint at scale
So when you have multiple teams working on a common product, you want to ensure reliability and predictability. This means that teams shall deliver on their commitments and release value on a frequent and regular basis. One of the fundamental way to do this is to make sure that all teams are having a similar Sprint length and that they start and end those Sprints at the same time. This way your teams are working with a similar cadence and are synchronized, useful for delivering integrated increment of value. A typical Sprint length for multiple Agile teams to work with is a 2 weeks period.
The Sprint Planning at scale
So now that we have a common length for our Sprints and that all teams start at the same time, we need to be aligned on what needs to be built for the Sprint. And this is done and committed to during a Sprint Planning. How this is done varies among frameworks – one common practice is that the key Product Backlog Items (PBIs) are presented by the Product Owner(s) to all the team members during a big room planning and that those items are assigned to the teams during this event (Sprint Planning Part 1). Sometimes, those assignments have been discussed before hand and only selected team members join this so called Part 1. Once the assignments are completed and communicated to all, the respective teams go to work on their detailed planning for the Sprint, this is Sprint Planning Part 2. If needed, the team members can coordinate with other teams during those sessions (we strive to avoid dependencies but they might be unavoidable) and any impediment/scope negotiation is done with the Product Owner(s). Once the Sprint planning part 1 and 2 are completed, the actual work can start.
Daily Scrum at scale
The best way to organize a team’s work for the day and align towards the progress on the Sprint goal is the daily Scrum. And this event will take place at team level like in normal Scrum. We are however adding here another event after this one: the scaled daily Scrum. This is to ensure that teams can communicate on their progress, impediments and work on removing dependencies between them. Some frameworks recommend to do this daily (scaled daily Scrum…), others recommend a once to twice a week synchronization only (SAFe for example). Best practice is certainly to do it daily but keep it short and timeboxed (15 mins max!). Note that only one to two selected members of each team should join this event – we do not want to drown the teams in Scrum meetings!
Sprint review at scale
The Sprint review is kinda of interesting there. This is the best event for inspection and adaptation. Two ways of doing it:
- Every team first hold their own Sprint reviews with a limited group of stakeholders and then a larger Sprint review is done with a bigger audience and all teams with a focus on demonstrating key features developed
- Having only one Sprint review where all teams demonstrate together their sum of work increments to all concerned stakeholders
In both ways, note the challenge of having an integrated sum of working increments from various teams. This is where common XP practices such as TDD, Continuous Integration, Continuous Deployment and Refactoring become paramount at scale. For more on XP, see Don Wells page here.
Sprint retrospective at scale
And this is getting better. It is still of paramount importance to improve at team level but you also need to improve the scaled system, right? So teams will still conduct a Sprint retrospective for themselves but we need to ensure that the overall system formed by the teams improve also. One elegant way of doing this is suggested by Nexus with the following: “Appropriate representatives from each Scrum Team meet to identify shared challenges (Part 1). Then, each Scrum Team holds individual Sprint Retrospectives (Part 2). Appropriate representatives from each team meet again to discuss any actions needed based on shared challenges to provide bottom-up intelligence. (Part 3)”
Backlog refinement at scale
In order to ensure that the teams do not get caught off guard with new stories which are not properly understood, refined nor estimated, backlog refinements are required – both at team and at scaled level. One way of doing this is to have selected members from each team to join a scaled backlog refinement where new stories are discussed, reviewed, refined and estimated. Those stories are then brought back and explained to the team members by their team representative for this event. Should discrepancies or different understandings emerge, this can be discussed later with the Product Owner(s) for clarification.
Now that we have presented the events at scale, let’s look at the roles…
Scaling Roles
Let’s have a look at team, Product Owner and Scrum Masters at scale.
The team at scale
The individual teams are still there and function with Scrum – however when scaling, you will inevitably have the need for a team to coordinate the overall efforts and ensure that the system delivers value frequently and reliably. This is the role of such a scaled team, they are like the pilots of the overall system. The scaled team can comprise of selected members of each team (they are split between their individual team and the scaled team) or it can be made of individuals only allocated to this scaled team depending on the model chosen. One thing that the Agile scaling models have in common: a need for product management and Agile coaching. This is covered in the next two paragraphs.
Product Owner at scale
The single most important role in Scrum is the Product Owner. You have a bad Product Owner, you will get a bad product. How is this role reflected at scale? If you have not many teams, you can get away with one single product owner who set up the vision, roadmap, priorities, collect requirements, sit with customers and with teams to understand, define and clarify requirements and needs. Once the work gets too big for one Product Owner, you can have a representative in each team who plays the role of the Product Owner/proxy Product Owner. That person will need to be in close contact with the customers and team as well as with the Chief Product Owner or Product Manager who sets the overall direction and requirements at large for the product. Finally, you may even end up with multiple members in a Product Management team in your scaled team who define the requirements and vision at large and then coordinate with the various POs sitting in each team.
Scrum Master at scale
The need to facilitate events at scale (Sprint planning, scaled daily, scaled review, retrospective…) and working on improving the overall system is greatly facilitated by a Scrum Master dedicated to this role. This role is referred as the Chief Scrum Master in Scrum@scale or Release Train Engineer in SAFe.
Other roles and teams
SAFe which is a rather comprehensive framework mentions the needs for a System Architect whose job is to define, set up and build an Architecture Runway with assistance and coordination from the various teams. Key point here is that one does not want the team to end up with different technologies or technologies not approved or conform with the company strategy and/or procurement. A noteworthy team in SAFe is the system team whose job is to provide a common toolchain to all development teams and assisting in integration issues or setting up system demos among others. Those teams and roles can be as good or as bad as you let them to be.
We have seen roles and events at scale and now we close the loop with artifacts at scale!
Scaling Artifacts
So our 3 beloved artifacts are: product backlog, sprint backlog and increment. Any idea on how they scale?
Product Backlog
The product backlog should be the single source of truth in a Scrum team. When scaling, you have two solutions:
- Keep only one product backlog to which all the teams refer to and work with
- Have one product backlog containing all the high level requirements (large stories/Epics also known as Features/Enablers in SAFe) and have a product/team backlog by team whose PBIs will be linked with those high level requirements in addition to any story that the team come up with
As an example for the second case, you would have one large PBI in the scaled product backlog which would translate into a dozen or more smaller PBIs present in a team product backlog. When the team PBIs for this large requirement are complete, the corresponding item would be considered done in the scaled product backlog.
Both approaches have pros and cons and need to be managed carefully. Important is to have visibility and transparency.
Sprint Backlog
Similar to the product backlog, you have two options:
- Have one Sprint backlog upon which every team refers to
- Have one main Sprint backlog and one Sprint backlog per team
Again both approaches have pros and cons
Increment and… the Definition of Done (DoD)
Last but not least, we should have a working and potentially releasable working increment at the end of every Sprint. This can already be challenging at team level but at scaled level, you need to ensure that practices such as Continuous Integration (CI), Continuous Deployment (CD), Test Driven Development (TDD) and refactoring are in place and executed diligently by the teams. SAFe recognizes the difficulty of such exercises and mentions that integrated product increment demos can lag as much as a week after the related team Sprint reviews. Finally and even more important than any other point: all the teams in the scaled approach should have a common definition of done (DoD). Without it, you end up with different quality criteria per team and may not be able to integrate the team’s work due to different understandings of what done means.
Conclusion
We have been covering in this article the main building blocks of scaling Agile and they all relate to the Scrum roles, events and artifacts. Once you understand how those work, you can have a look at the philosophy and details of how each scaling framework operates before making the choice on which one to use to guide you. But in any case, the basic mechanisms on how they operate are very much the same so you could even end up with your own version. But remember: Scrum is the base and shall be executed properly at team before any attempt to scaling. You have been warned and may the Force be with you! 😉
