Scaled agile framework made it easy for handling development and delivery even with larger and multiple teams. It still did not compromise in the Agile Manifesto. This framework is in general referred to as the Safe methodology in the industry.
Managing projects in an efficient manner became easy with agile approach. It is an iterative process that helped in saving the cost and time of the resources. Also, it avoided redoing the entire work as the team worked collaboratively and met for daily stand up meetings, sprints, and sprint retrospective to make changes iteratively. This gave a great sign of relief from the traditional method.
Having said that, this method also had hiccups when larger teams or multiple teams were involved in development and delivery. Scaled Agile Framework ® addressed this issue and fine-tuned the process there as well to live up to the Agile Manifesto. This framework is in general referred to as the SAFe® methodology in the industry.
Let us understand this methodology in detail using this guide which is carefully drafted for all those who wish to update agile at the enterprise level.
First things first – Definition and Intro
Application of lean-agile practice to enterprise-level projects can be done with the help of this scaled framework. The three sections of this framework are team level, portfolio level, and program level. The SAFe® agile framework has built its base on agile and lean principle. The purpose of Safe methodology is to match the expectation of the entire organization's stakeholders.
Dean Leffingwell is the father of the SAFe® framework. He is the co-founder of scaledagile.com which is functioning since 2011.
|Release Year||2011||2014||2016||June 2017||3rd Oct 2018||Expected Jan 2020|
Roots of SAFe®
When should we use Safe Methodology in Agile
- - Sub epics – Smaller user stories or story allotted to each team
Top 5 situations to use SAFe® agile methodology for improving the organization performance 5x
- Agile implementation to be done consistently across multiple teams and larger portfolios.
- Teams that always face challenges in managing time in delivery.
- When the team requires independence, the organization can allow this model and manage things by objective
- Improving the development lead time for scaling the organization to the next level.
- When there is a lack of clarity on role, then the team can apply this model to take ownership to implement things effectively.
Difference between SAFe® and other practices followed in agile
|S.No||SAFe®||Other practices (AGILE)|
|1||It is available for free and in public domain||Not all are available for free and in public domain |
|2||Level specific but lightweight||Lightweight but not specific to levels |
|3||Easily usable form ||Not approachable|
|4||Constantly upgrades matching agile practices||Not much of upgrades evident officially |
|5||The agile practice is grounded to the enterprise level||Agile practice for small level|
|6||The entire software development process is covered ||Only partially covered |
|7||Visible and transparent ||Visible and transparent |
|8||SAFe® is for enterprises||For teams|
|9||Agile release train (ART) to program||Sprint for teams |
With this basic introduction, let us move into the basic foundation of SAFe®.
Basic building block
The framework lies on the following basic building blocks and that form the strong foundation of SAFe®.
|Alignment ||Built-in quality ||Transparency ||Program Execution |
3. Leaders – Lean-Agile
- Improvement of lean-agile development
Basic 7 characteristics of the lean-agile leader include the following
- Leading to change
- Learn as though it is a lifelong process
- People development
- Minimizing constraints
- Inspiring and aligning the team with the mission
- Decentralizing decision making
- Motivating the workers
4. Mindset – Lean-Agile
5. Practice communities
- Domain – The common interest area - WHAT is cared about – Interest
- Practice – skill, techniques, and experiences shared – WHAT is done together – Techniques
- Community – Team of people who work together with a common goal and interact regularly to achieve the goal – WHO does it.
- Scrum master from various agile teams group together to form a CoP. They exchange their practices, and experience to make their agile team highly productive.
- CoPs consisting of testers and developers form an automated testing community.
Stages of development of CoPs:
|Need for CoP team is discussed and agreed to form a team||People are elected to play a role in the CoP team||CoP team is in action and they start working together sharing details and resolving issues thus enhancing the practice||Practice improves as problems are resolved||CoP team dissolves as |
Levels of the CoPs
There are 5 types of members present in the CoP team namely the core team, active, occasional, peripheral and transactional.
- The core team includes the nucleus of the CoPs who will make decisions.
- The active team consist of people who work actively
- The occasional team participates only for a specific need and dissolve
- The peripheral team is an extra team which get engaged on a need basis
- The transactional team will connect for completing the transactions
The steps in implementing the framework in lean-agile practice are 12. It is briefly described and based on your project you may want to get into the detail of each step to accomplish the goal.
1. Vision identification by reaching the tipping point
2. Provide training to the lean-agile change agents
3. Offer training to all the executives, leaders, and managers
4. Creating a CoE based on lean-agile principles
5. Make a note of the ARTS and value streams
6. Creating a detailed plan
7. Getting ready for agile release train launch
8. Training the team and concurrently launching ART
9. Coaching for executing ART
10. Launching more value streams and ARTs
11. Extending the portfolio
12. Sustaining and improving
We call this an Implementing 1-2-3 model and stage 1 is identifying vision, providing training, and creating a CoE. Stage 2 is to work on ARTs identification, planning, and launching. Stage 3 is to extend the portfolio, add more ARTs, and improvement.
SAFe® and its levels
- Value stream
|Roles Across Levels |
|Portfolio ||Large Solution||Program||Team |
|Enterprise Architect ||Manager ||System Architect ||Development|
|Epic Owner ||Architect ||Product Manager ||PO|
|Lean Portfolio Management ||Engineers/Trainee||Release Train Engineer|
|Business Owners |
|Ceremonies Across Levels |
|Solution Demo||PI Planning||Iteration Planning |
|Pre PI||System DEMO||Review|
|Artifacts Across Levels|
|Strategic Themes||Solution Intent ||Feature||Stories|
|Portfolio Canvas ||Enabler Capability||PI Objectives ||Iteration Goals|
|Epics ||Backlog ||Program Board||Backlog|
|Business Case Lean||Enabler Feature |
- Identify à Elaborate à Prioritize à Schedule à Implement à Test à Accept
- Iteration steps
à Increment of new functionality
à Repeat pattern till accomplishment
à Iteration planning
à Commitment to functionality
à Iteration execution
à Demo for new functionality
à Retrospective meeting
à Repeat the same process for next iteration
Role of each key stakeholder in program level
- Product manager – Program manager to prioritize the backlog
- The system architect collaborates with the daily work and keeps a check on the non-functional requirement being met. They work with the enterprise architect (portfolio level) and ensure the architectural runway is sufficient.
- UX designers interface the design and user experience.
- Scrum Master plays the role of a release train engineer
- DevOps team works to deploy the software to the customer and takes care of delivery.
This level shows the highest level of concern in SAFe® and provides a basic block for organizing the flow in multiple value streams. It allows the system and solution to develop and is described by the strategic theme. The objectives are met at this level by making a budget and streamlining the governing mechanism. It has a bidirectional connection with the business. One is the strategic theme that guides the business and another one is the flow of the portfolio values. A value stream is a key goal on portfolio and hence it funds the people and resources for building a solution. The concepts adopted in this level include a connection with the enterprise, program portfolio management and portfolio epics flow management.
As already mentioned this is an optional level in SAFe®. It is present when there are more than 100 people on the team. Typically following enterprises include this level who requires an independent, large-sized team and complex solutions. Multiple ARTs are used and include several suppliers.
Minimum 100 practitioners are required to build this system. This can be kept optional and expandable and keep it in a collapsed view when built by less than 100 practitioners. Additional constructs, coordination, artifacts are required to build this solution in a lean-agile pattern. Value stream engineer, solution architect, and solution management team are the additional stakeholders who play a significant role in making a decision at this level.
The table below explains the role, event, and artifact of all 4 levels in SAFe®. The details of all this need explanation which you can understand from the theory given above. Further, we suggest you apply for SAFe® training and hear from experts to master scaled agile framework.
| Team|| Program|| Portfolio|| Value Stream|
Release and product management
Leaders - lean agile
Program portfolio management
Release and solution management
RTE - Value stream engineer
Coordination - Value stream
Epics - Value Stream
Kanban - Value Stream
Backlog - Value Stream
Coordination - Value stream
Planning for sprint
Daily stand up
Inspect and adapt the workshop
Release any time
Strategic investment planning
Kanban Epic planning
Pre PI Planning
Post PI Planning