Understanding Scaled Agile Framework – SAFe

What is Scaled Agile Framework (SAFe)

Scaled Agile Framework SAFe A proven, publicly available framework for applying Lean-Agile practices at enterprise scale and is the property of Scaled Agile, Inc.

Every company big and small is following some variant of Agile. Organizations in the quest for iterating on smaller features, developing and delivering faster have pushed all their teams to take up some flavor of agile be it Scrum, Kanban, Scrumban, Extreme programming, etc.  

Once the teams start working in an agile fashion delivering faster, they normally realize that they have kind of given up speed for predictability and their ability to cohesively ship something as a whole organization. The ultimate quest here is to somehow align all the agile factions towards a common goal. A singular organizational vision and for one individual like a Sr. Program / Project Manager to be able to say with certainty how and when certain aspects of the vision are going to be delivered.

Having all the teams march to a set rhythm in a large organization is indeed hard. To accomplish this you need to have Product owners who are willing to communicate with openness and understand the underlying vision and them having the ability to evaluate and prioritize every feature the team is working on pitted against the fundamental goal the organization has set.

Agile software development methodology states its pillars where individuals, interactions and cross-functional teams are valued over processes, comprehensive documentation and set-in-stone plans, which have been nothing if not disruptive for big companies used to tight controls on developing the custom software they need to run their business.

The marriage of the fundamental principles of Agile and delivering with predictability is the most well-known “Enterprise Agile Framework” is known as SAFe and hopes to accomplish this.

Historically, scrum, extreme programming and other agile methods tend to focus, and stop, at the team level. SAFe presents a single, unified view of the work to executives, allowing them to drill down for details or up for trends and analysis.

These teams are in theory to be independent cross functional team empowered with the knowledge and skills needed to deliver a feature. The executive level teams help in breaking down the vision for the year into comprehensive features for the teams and work with the Program Managers to execute features of the vision. The executive team along with the Program managers manage the portfolio of features, prioritize, cost and time the release of the whole list of features.

Why is this Complex ?

The issues here are that most scrum teams are not built to complete features end to end. Though there is a movement to have a full stack development team and there are advantages of doing so, it is clearly a double edged sword for many reasons. One of them is that a full stack team has higher learning curves and requires more manpower to to keep up with ongoing modifications and upkeep of the features they own. Also the complexity of certain applications requires a highly skilled developers who is an expert at various technologies. A full-stack developer loses to a specialist and most larger organizations have specialists. Developers who focus on a particular stack.

Agile Release Train (ART)

The SAFe framework aligns teams to an Agile Release Train (ART). Each team could consist of anywhere from 40 people to 150 people who plan and are responsible for delivering a Release Train. These individuals meet at the time when the features for this release train are planned. The representatives of these teams meet at least once a week or daily depending on the type of project and the level of coupling between the teams at the Scrum of Scrums (SOS) and discuss progress, blockers and plan the week ahead.

SAFe breaks the entire team into –

• Team
• Program
• Portfolio

When the Release Train (ART) has so many people it is recommended that one person responsible for driving all the teams, making critical decisions, and unblocking the teams. This role naturally falls into the hands of a well-experienced Program Manager, Project Manager to take on the role of an Uber Scrum Master who is both  accountable and acts as the final decision-maker.  

Every feature is tied to a release train, has a set release date. The train has a budget and set milestones that the team has committed to. A release train is a long-term approach that may have many smaller development teams and projects inside of it. Deployments can still be done on a daily or weekly cadence but the goal is that it should be complete at the agreed-upon milestone. Ideal or general duration of a ART is a quarter. There are a few companies I know that are currently following this process and T-Mobile is one of them.

T-mobile uses this to launch certain initiatives, since these need to go out on a certain date and requires the entire org i.e various business units to all come together and deliver various pieces to make an entire portfolio complete. This becomes imperative that every team that is responsible to get on the various milestones like the development complete, test complete, and integration testing complete dates. An older version of the SAFe framework was also suggested.

SAFe Development Principles

The SAFe Framework does prescribe some development principles that adhere and are more conducive to better practice the framework. Some of them are :-

• Agile Architecture
• Continuous Integration
• Test First
• Re factoring
• Pair Work
• Collective ownership

A common thread is an iterative approach with strong testing and Continuous integration. I will not be describing each of these in this post but as you can see most of these principles are fundamental agile tenets.

In addition to these principles SAFe also describes Burndown charts and potentially shippable increments (old terminology) instead of sprints.

The other way of looking into the SAFe framework is as an extension of the existing Scrum teams and is built on top of that. Is it truly a question .. More on this below 🙂

Tools & Certifications

From a Tools perspective, both Rally and JIRA now have the capability to manage work-blocks /User Stories to assign them to features, Initiatives and portfolios items which then can be put on a release schedule. You also have release Train Boards that give you a full view of all the items in a release and the progress made on each item. JIRA’s greenhopper also gives you some cool burn-down charts and predictions on when the release would be complete at the current burn rate.

There is a Scaled Agilist (SA) certification program all members of your team who need to be involved and are responsible for leading SAFe implementations. A great book to learn more is the The Rollout: A Novel about Leadership and Building a Lean-Agile Enterprise with SAFe®.

See also: Agile Implementation

Insight into the Evolution of the SAFe

Ken Schwaber in a blog says that the SAFe was simply a re-brand of the Rational Unified Process (RUP) framework that was built and productized by IBM. He also goes on to say that Dean Leffingwell who was the primary author on the very first iteration of the SAFe Framework was the SVP of  Rational Software owned by IBM and that many individuals who sell the framework are from  IBM. That’s Ken for you giving insight into where it came from and that it was not part of the original Scrum thought process.

In my opinion, the SAFe is an extension or an amalgamation of several existing agile practices but it also picks up on certain Waterfall aspects.

Conclusion – SAFe or something similar has become a necessity for larger organizations, which need to deliver a set of features with some degree of certainty.

Recommended Reading: The Rollout: A Novel about Leadership and Building a Lean-Agile Enterprise with SAFe®