Very often, I over hear discussions on scaling agile frameworks that helps enterprises to build a strong base for business agility. Let me tell you, it is not an easy thing to scale, since the enterprise level challenges multiply as you look upwards. Added to the chaos there are multiple frameworks flooded in the commercial market for scaling agile. It is easy get confused while understanding the nuts and bolts of each framework.
As you know, in a typical scrum team, there are multiple roles and personas that work together to complete the set of work items that they have committed to accomplish within the sprint. The scrum team members are bonded together by their working agreements to accomplish the sprint goal. But, it is all not that simple! Did you ever imagine how this team works in complex projects, involving dependencies across multiple teams? What if, there is a project with 500+ people, all have to work together to build a bigger piece of working software? So, probably this might be the starting point of all problems and frustration.
Scrum of Scrums (SoS) is an important and well known technique in scaling Scrum to large project teams. It is also known as Meta Scrum. These meetings allow teams to discuss their work, focusing on areas of overlap and integration. In this approach, each team identifies oneperson or two persons to represent their team to attend Scrum of Scrums meeting. The representatives from each team coordinate the work with multiple scrum teams. These meetings are much like daily standups, but they may happen less frequently as the project execution proceeds in a smooth manner. Everyone answers the following three questions:
- What changes did my team just make that will affect you?
- What changes will my team make next that will affect you?
- What blockers do we have or foresee for you?
In some project teams, this meeting happens 2-3 times in a week. It may start with a 30 minute time box initially and later reduce as the release progress.
It is important to note that it is not a status meeting; in fact it is differences only meeting to understand the other team’s progress. The members who take part in this meeting are self-organizing and self-managing. Managers are welcome to this meeting and they may offer their helping hand in removing bigger impediments. This meeting is a working session to resolve the issues, to focus on inter-team dependencies that effect process and people. Use simple spreadsheet or any other tool to track issues, owners and due dates.
Hmmm…that is a lot of work, for someone who wants to try SoS!!! Isn’t it.
On the other hand, we have Scaled Agile Framework (SAFe), which is a brain child of Dean Leffingwell that focuses on adapting Lean-Agile framework that is built on the top of Scrum teams. The framework could be successfully applied for projects with 50-125 people at a stretch and supports large enterprise scaling of Scrum.
The big picture graphic of SAFe highlights individual roles, teams, activities and artifacts that are applies the framework at team level, Program level and Portfolio level. The core values of SAFe are Program Execution, Code Quality, Alignment and Transparency. SAFe uses Agile Release Train (ART) to coordinate between multiple Scrum teams, which advocate the concept of “Develop on Cadence and Release on Demand”. SAFe supports agile frameworks like Scrum, XP and Kanban. It supports more centralized top down large enterprises that highly resonates with Process and Product evolution.
It also proposes an architectural runway that multiple scrum teams need to build to have high quality product increment. Lots of new Jargon in SAFe, but it creates an impression that we are trying a new thing.
Other framework often debated in agile community is Large Scale Scrum (LESS), which was brought into existence by Craig Larman and Bas Vodde. LESS proposes 2 frameworks for coordinating with multiple Scrum Teams. The first almost works similarly to operation of Scrum of Scrums meeting for 10 teams. The number 10 being not a magic number, but it is the tipping point beyond which a Product Owner no longer can have a big picture view and have no time to spend with multiple teams. Apart from Scrum of Scrum style, the team representatives from all Scrum teams will do all the scrum ceremonies together.
Beyond 10 teams, the second framework which comes into being that states that the Product Owner role needs to be more top down to have holistic big picture view. The Product backlogs are split into area backlogs and the Product Owner role is divided into Area product Owner and the Product Owner Team.
These two frameworks actively support Scrum teams in large enterprises. They have systems thinking view in Agile and scale the PO structure.
Few parameters which may be used for evaluating scaling frameworks are completeness and coverage of all levels of the framework, its popularity and support available from the creator of the framework, typical cost to implement, different low level frameworks like Scrum, XP, it supports etc. Though some of these scaling frameworks come at cost, I believe essential to carefully evaluate a framework that fits the overall goal and strategy of the organisations