“Those who master large scale software delivery will define the economic landscape of the 21st century” – Mik Kersten

In today’s day and age, agility is the only way that guarantees continuous progress by allowing you to have awareness of what really is desired by the end user.

Some relevant facts:

• 7/10 companies are adopting agile (source: Capterra)
• 98% of the companies that adopted agile, have benefitted (source: SwarmOS)
• The companies benefitting from adopting agile have 60% increase in revenue and profit growth (source: Harvard Business Review)

Undoubtedly, becoming agile is the only way forward.

Adopting agile is done through any framework that falls under the agile umbrella. These frameworks consist of events that are catered to support development and deployment for all team sizes. Scrum, for example, is a very popular agile framework that is ideal for an agile team size of 8-12 members. It consists of ceremonies like, planning, sprint execution, sprint review and retrospective. But in this article, we shall only be discussing how planning and execution is done in different renowned agile scaling frameworks for multiple agile teams that might be located remotely.

1. Scaled Agile Framework (SAFe)

Participants

1. Product Owner
2. System Architect
3. Release Train Engineer
4. Business Owner
5. Product Management
6. Scrum Master

Planning and Execution

In the Scaled Agile Framework, there are multiple agile teams working on a cadence in sprints, to deliver one solution in a Program Increment (PI) that can last for 8-12 weeks.
These agile teams are part of an Agile Release Train (ART) that band together to develop iteratively and deliver value incrementally.

The planning for developing and delivering the features that will be done in the PI, are done in the PI Planning. The date for the PI Planning is decided and confirmed in advance and the upcoming PI Planning events are also planned.

The planning event lasts for two days with an agenda, where all the events are planned and timeboxed. All the teams that are onboard an Agile Release Train sit together and plan to produce PI Objectives that shall be achieved in a Program Increment.

Below are some of the highlights of PI Planning:

• There is a single Product Backlog.
• Product Management owns the features.
• Product Owners own the Stories that need to be implemented by the teams.
• Development Teams estimate the stories they are working on.
• The vision, business context, architecture, risks and dependencies are discussed.
• PI Objectives are set.
• Confidence Vote is done to assess if the teams feel confident in achieving the planned objectives for the PI.
• At the end of the PI Planning event, there is a retrospective event that inspects what has been planned in the PI Planning session.

The Agile teams in the Agile Release Train deliver in sprints through a continuous delivery pipeline. Continuous integration is an ongoing process during the development in the Program Increment where the items are taken from the backlog and they go through the following processes:

1. Develop: The best practices for developing the stories and committing the code
2. Build: Having a uniform development environment for merging the code
3. Test: Validating the solution that is built
4. Stage: The practices for hosting and validating the solution in a staging environment before rolling it into production

This helps in improving the quality of the solution, reduces risks and helps establish a consistent development pace.

Along with having strong integration practices, there are daily stand ups amongst teams that are conducted by the scrum masters, sync up between scrum masters of different teams in the Agile Release Train and meet-up of all the product owners of the teams that help ensure continuous collaboration and alignment with one another of the work being done.

2. Nexus

Participants

1. Scrum Teams
2. Scrum Master
3. Product Owner
4. Nexus Team
5. Nexus Integration Team

Planning and Execution

In the first stage, the Nexus Product Backlog is refined. The Nexus Team plans the bigger picture and discusses any impediments that can be faced. Outcomes from this are utilized by the scrum teams for their planning.

The Scrum Teams sit together and plan for the sprint. They pick out the items from the refined Nexus Product Backlog which can have stories, tasks, business initiatives or epics. Each Scrum Team adds these selected items to its own Sprint Backlog.

While each team maintains its own sprint backlog, The Nexus Sprint Backlog is formed with all the team’s selected product backlog items to enhance visibility in the work being done.

At the end of the sprint planning there is a Nexus Sprint Goal that aligns with the product goal and describes the purpose that will be achieved by the Nexus during the sprint.

Nexus Daily Scrum is done when each member from the scrum team meets with the Nexus Team. All scrum teams have their respective scrums with the Nexus Team.

3. Large Scale Scrum (LeSS)

Participants

1. Product Owner
2. Area Product Owner
3. Scrum Master
4. Feature Teams

Planning and Execution

There are two ways for LeSS implementation:

1. Basic LeSS that has up to eight teams (of eight people each).
2. LeSS Huge is for up to a few thousand people on one product. Items are in basic LeSS while Epics exist in LeSS Huge.

The mode of planning is the same for both the types of LeSS.

The teams select items from the single Product Backlog and then they are discussed by the team. This discussion involves planning on how to complete those items in order to achieve the sprint goals. At the end of the planning, sprint goals are set.

Daily Scrum is held independently by each Team, though a member of Team A may observe Team B’s Daily Scrum, to increase information sharing.

One Definition of Done for all teams for a deliverable product that is created in every sprint iteratively and incrementally.

A product backlog refinement session is done where the customer and the teams discuss how the existing requirements can be improved, or if new requirements should be added.

DevOps and Continuous Integration ensures smooth delivery to the customer where a deliverable is a shippable increment at the end of every sprint. Teams are feature-oriented and regularly integrate their work with one another that helps in reducing dependencies using the same code base.

Spotify Tribe

Participants

1. Squads are self-managing and self-organizing teams that consist of 6-12 members responsible for developing the solution. Each squad has a product owner who is responsible for defining the feature area and each squad has a direct contact with the stakeholders. There is an agile coach who is the servant leader to their squads and provides guidance.
2. A tribe consists of multiple squads that work on one feature area which has 40-150 members. A tribe lead is responsible for creating a productive and an innovative environment for the squads.
3. A Chapter has specialists with individuals from different squads grouped into one and formed within a tribe. A chapter lead is also a line manager and supports them in their personal growth and facing specific challenges.
4. Guild is an informal group that has people from different tribes, who have a common interest. Any person from any squad, chapter or tribe can be a part of a guild.
5. A Trio is formed when for every tribe there is a design, product area and a tribe lead.
6. Alliance is a combination of three trios. It is led by a product, design and a tribe lead.

Planning and Execution

The feature is first defined using a narrative or an elevator pitch. Prototypes can be used to get a feel of what the feature would look like. The prototype is shown and after receiving feedback, a MVP is created that is just enough to fulfil the feature requirements.

A squad works on a specific feature area and has a mission to complete. There is an agile coach and a product owner for every squad. The agile coaches are servant leaders that help in removing impediments, run sprint plannings, retrospectives and coaching within the squad or providing any guidance and in maintaining the overall culture. Each squad has its own product owner that is responsible for prioritizing the work done by the squad.

The squads plan what they have to achieve. They can choose to have sprints or not of lengths that suit them. The squads are not bound to follow agile practices rather they are free to apply any practice such as scrum or kanban for their daily tasks that suit them.

The solution is released in small and frequent increments as the features are gradually rolled out. If there is a large project to deliver, then it is broken down into smaller chunks and delivered iteratively.

To keep all of these squads in sync, release trains depart on a set time with all the features. There might be some features that are not complete so they can be toggled hidden. And in the next release it can be made visible.

The squads deliver complete and few incomplete features. The reason for having these incomplete features is that it helps expose any integration issues or problems that can be fixed later on. Small releases are done frequently. A feature is first rolled out to a small percentage of users. After applying A/B testing techniques and attaining feedback and making any changes the feature is then completely rolled out to all the users.

The squads are loosely coupled but tightly aligned. The squads are constantly in sync with each other while the Product Owners of the squads are in constant communication with one another. Squads need to be aligned with each other with product strategy, company priorities and other squads.

Dev and ops work in such a way that the operations do not interfere with the work of the developers. Rather the operations pave the way for the developers to release the work for themselves. This is done by creating an environment such as building an infrastructure and the support to let the developers launch their work. Face to face communication is encouraged over documentation.

To Wrap it All Up

Adopting agile is not an easy feat. It takes time, patience and most importantly, support from the leadership. To ensure agility, implementing any of these frameworks needs to be done completely from the bottom up to reap its full benefits. Apart from focusing on the practices that guide on “How” to work, it is also important to develop a Lean Agile mindset which focuses on the “Why” aspect of the things that need to be done.

Developing trust among all the team members is essential for being successful. To arrive at the state of trust, the key ingredient is maintaining transparency of the work done. This is often ensured by means of a physical or a digital board where all the work items are clearly displayed for everyone to see.

While there are many options available in the market, Kendis is the only solution that addresses your needs purposefully and powerfully. The Kendis digital program board is designed to respond to every scaling agile methodology, equipping you with the ability to transparently visualize all of your epics, features, stories or tasks with all the interconnected dependencies and risks. Thus, truly becoming beneficial in not only bringing together and aligning all of the members of the organization but eventually helping in building trust and better inter team relationships. This is why organizations that aim for scaling agile smartly, prefer to partner with Kendis.