Get certified - Transform your world of work today

Close

Practicing Scaled Agile

A model for scaling Scrum

8 June 2015


I've been practicing the scaled Scrum model described in this article for more than a couple of years. My team's transformation to Agile has become the benchmark for Agile practices in my organization.

Agile kickoff

We started our Agile journey in one big bang! All team members underwent training in Agile, Scrum, and scaled Scrum. All Scrum teams began to practice Agile at the same time. I have seen in other groups that only one small Scrum team practiced Agile and, based on the results of that team, the rest of the teams in the development group decided to move ahead with the transformation. I support the first approach, in which all the Scrum teams start practicing Agile at the same time.

Scaling to multi-Scrum teams provides the following benefits:
  • Everyone speaks the same language.
  • The time and effort necessary to migrate to Agile is reduced (it's a one-off exercise).
  • Dependencies are addressed and solved easily.
  • The Agile maturity of the multi-Scrum teams is the same.


The big picture of scaled Agile

The following diagram illustrates the big picture of the scaled Agile model:

 
To use this model for scaled Agile, you must implement two "runways": the architectural runway and the program runway.

Architectural runway

  1. Separate architectural epics are created for technical feasibilities before starting the project.
  2. Architects and system engineers own these epics.
  3. Architectural epics flow to PIs (product increments) and are completed as part of the program runway.
  4. Based on the team's inputs for each sprint, the project takes off.
  5. After the project starts, it moves to the program runway.

Program runway

PI planning meetings include the following activities:
  1. The program runway consists of PI (product increment) release trains.
  2. A PI planning meeting is held at the beginning of every PI.
  3. Product owners (POs) define the objectives for the current PI, based on the highest-priority features to be implemented.
  4. Product owners set the objectives so that program or product growth is realized at every PI.
  5. Product owners set additional objectives known as "stretch" goals.
  6. Regular PI grooming meetings are conducted to secure the Definition of Ready (DoR) for PI planning meetings.
    • Defining the objectives for the PI for each Scrum team is based on the prioritization of features, which the PO likes to see early in product development.
    • Scrum teams agree to objectives based on their capacity. Otherwise, the teams will need to negotiate the product scope with the PO.
    • The teams Identify and discuss the dependencies among themselves.
  7. Every PI has four sprints, each with two-week timeboxed iterations.
  8. Within a sprint, typical sprint rituals, such as sprint planning, sprint demo, and inspect-and-adapt sessions, are practiced.
  9. A backlog grooming meeting is held for each sprint to ensure that the DoR is complete for the next sprint planning and to groom the stories from the backlog.
  10. The acceptance criteria-driven development (ACDD) approach is rigorously followed.
  11. In a near-term PI, the last sprint is spent on release-ready activities; otherwise, the sprint is spent on the following activities:
    • Grooming the PI backlog for epics
    • Innovating and prototyping (unrelated to projects)
    • Addressing technical debt
  12. An SoS (Scrum of Scrums) meeting is conducted every week for discussing and resolving any dependency issues and risks among Scrum teams.
The PO can modify the PI objectives of the Scrum team, based on business priorities during the PI.

Applying best practices during the scaled Scrum journey

Over the last 16 PIs, we have implemented many best practices. Some include one or more of the following generally adopted Agile practices (GAAPs):
  • Hold a meeting for the backlog grooming of stories and epics for every sprint. A detailed grooming session on prioritized epics is held during the last sprint of the PI.
  • Implement the ACDD approach to burn the stories.
  • Apply the DoD to each story to claim completion of a feature.
  • Perform timeboxed code refactoring on an as-needed basis.
  • Use the work-in-progress (WIP) limit to adhere to the "stop starting, start finishing" strategy.
  • Pair up with other members for complex features or when a new member joins.
  • Effectively use the continuous integration (CI) infrastructure. Tools for code coverage and static code analysis are integrated with the CI infrastructure. CI manages the builds, runs test cases, and sends reports.


The result

As a result of implementing the scaled Scrum model and related best practices, we have not missed a single milestone for our projects in the last 34 months. A few metrics are tracked to monitor and control the health of sprints and the PI. The Say-Do ratio and estimation accuracy are captured at every sprint and PI, whereas the business value gained is calculated at every PI. With a couple of exceptions, all Scrum teams have achieved more than an 80% Say-Do ratio.

Conclusion

There are many approaches and techniques to scaling Scrum. We have been successful with implementing the model highlighted here.


Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.



Article Rating

Current rating: 3.5 (8 ratings)

Comments

Nishanth Hydru, CSP,CSM,CSPO, 6/16/2015 10:36:56 PM
Good one, Prakash!
Prakash Mallappa Pujar, CSP,CSM,CSPO, 6/18/2015 8:34:01 AM
Thanks Nishanth...
SenthilVel Marimuthu CSM CSP SAFe-SPC, CSP,CSM, 12/23/2015 4:37:07 PM
Good one Prakash!
Maheswara Rao Gorle, CSM, 4/24/2016 6:21:04 AM
Very helpful, Thank you Prakash.
Michael Jude Fernandes, CSM,CSPO, 5/22/2016 1:41:17 AM
Nice!!
Ali Bentaleb, CSP,CSM, 6/23/2016 9:05:48 AM
Good. This is a small SAFe

You must Login or Signup to comment.

 
The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.


 

Newsletter Sign-Up

Subscribe