What is Scaling scrum?

Scaling in scrum would be defined as the way how the functionality from each set of Scrum teams should deliver and interoperate. It may take longer and only do as much as the nine or so teams can do at once.

Scrum at scale is a based on a development unit called a Nexus. Nexus consists of up to 10 scrum teams, the domains understood, organized people and the number depending on how well the code and design are structured.

Nexus would consist of Events, Roles, practices, and artifacts which weave and bind the work together in order to produce a whole.

It is found that when there are ten scrum teams, their ability to create usable product would fray. Dependencies and complexity would need an overwhelming solution. Ability of creating a "done" increment and not leaving a pile of technical debt behind would be intimidating without any shortcuts which would reduce product to work successfully.

Scrum, as originally outlined in the Scrum Guide, is a framework for developing, delivering, and sustaining complex products by a single team. Since its inception, its usage has been extended to the creation of products, systems, services, and processes that need the efforts of multiple teams. Scrum@Scale was created to efficiently coordinate this new ecosystem of teams. It would achieve this goal by setting up a "minimum viable bureaucracy" through a "scale-free" architecture.

Dr. Jeff Sutherland developed Scrum@Scale based on the fundamental principles of Scrum, game theory, object-oriented technology, and Complex Adaptive Systems theory.

Scaling Agile with Scrum of Scrums

Among all the various Agile Frameworks that are used currently, Scrum of Scrums (SOS) is a traditional and most commonly used. Ken Schwaber and Jeff Sutherland are the two individuals credited with the introduction of the Scrum of Scrums.

Scrum of scrums is a technique that is used to scale the scrum up to huge groups consisting of dividing groups into agile teams of 5 – 10 members. A daily scrum within a sub-team would end by allocating one team member as an "ambassador" to participate in daily meeting with the ambassadors from other teams, known as scrum of scrums.

Based on the context, Ambassadors may be the technical contributors, or Event manager or a Scrum master.

Scrum of Scrum teams would proceed as a daily normal meeting, with the ambassadors who would be reporting completions, impediments, and nest steps on behalf of the teams they represent. Impediments would be resolved by focusing on the challenges of coordination between the teams. Scrum of Scrum would track these items through a backlog of its own where each item would contribute in improving the team coordination.

Running SOS meetings

A coordination of various teams is done in a Scrum of Scrums meeting which can be conducted daily, twice a week, at a minimum of one week. Every Scrum team would have its Scrum Master or a designated team member who would attend the Scrum of scrum meeting as its representative. If a team wants to discuss a highly technical material, both the scrum master and technically expert should attend the meeting.

The Scrum of Scrum meeting is run very similarly to the Daily Scrum meeting which is conducted on a daily basis but is not limited to a fifteen-minute timebox. In this meeting, each team's "ambassador" would respond to the below questions:

• What was the team's accomplishment since the last meeting?
• Problems occurred and if any, then did they affect your team negatively?
• What would the team accomplish before the next meet?
• What would be the output from the team in future sprints do you see as possibly interfering with the work of other teams?
• Does your team have any interference problems coming from the work of other teams?

The purpose of the Scrum of Scrums meeting is to ensure the integration and coordination of output from the various teams by eliminating all impediments. In order to keep track of all of this, the Scrum of Scrums should have a Product Backlog of its own to be maintained by the Chief ScrumMaster.

Agile Release Train

What is Agile Release Train?

An Agile Release Train is a Release cycle that is already preplanned which is stringently planned into the phases of individual projects or BAU release teams should align in order to deliver this release.

The main reason for the release teams need to align to these trains is because they have changes which impact other parts of the organization outside of their own system changes, which may require the use of shared SIT test environments. In most cases, agile release trains would be set up as a quarterly delivery window but span up to 10 months due to planning and integration dependencies.

When release or delivery team's setup these trains, they usually communicate to various system teams in advance (sometimes several months in advance) and publish them on a Release Schedule. The actual reason why release trains are published months in advance is purely to allow various technology and business units to plan and book in their releases and changes so that impact and dependency assessment activities would take place.

The Structure of an Agile Release Train

An Agile release train is a very formal and structured process which would require a meaningful data to ensure teams who join the agile release train can make a judgment around their suitability in formally joining. When the train is setup there is almost always some foundation data required. This would include:

1. Release details (release id, deployment date, name, release type, risk level, – Enterprise, Program or Portfolio etc)
2. Release phases and scheduled dates per phase.
3. Tasks and Activities to be completed for each phase.
4. Stage gates and Milestones.
5. Key stakeholders would be responsible for managing the enterprise agile release train.