Here I make the case for installing SAFe as-is. Note: Be sure and read to the end!
The Case for Installing SAFe As-Is
Installing SAFe as-is is appropriate when you have all of these situations:
- We need to “scale Agile up” to levels higher than Team-level
- Each team needs consistency of using ScrumXP or Kanban
- XP practices are needed to improve the quality of the deliverables
- An Iteration Planning meeting is needed to map out the next 2 weeks
- Iterations are on a 2-week cadence for everyone
- A Team Sync with each team member is needed for the Team to remain in sync
- An Iteration Review is needed to demo the working product increment for feedback
- An Iteration Retrospective is needed for the Team to improve
- A Scrum Master role is needed to ensure Scrum is leveraged well within the Team
- A Product Owner role is needed to manage the Team Backlog
- Agile Teams are needed to define, build, test, and deliver an Increment every iteration
- Agile Teams practice release on demand
- Agile Teams use DevSecOps principles to ensure frequent releases
- Team-level work items are sequenced in the Team Backlog
- A Team Kanban is needed to manage the Stories as they flow through
- The Iteration Backlog is needed to show the selected work for the next 2 weeks
- 2 types of Stories are needed: Business Value User Stories and Enabler Stories
- Metrics are needed at the Team-level to inform outcomes, flow efficiency, and competency
- Agile Teams are virtually aligned around the flow of value into Agile Release Trains (ARTs)
- Agile Teams participate in PI Planning at the start of each Program Increment (PI)
- Program Increments are needed on an 8 – 12 weeks cadence
- The last 2 weeks of the PI are reserved for Innovation and Planning
- In PI Planning, each Agile Team formulates its PI Objectives
- In PI Planning, a Program Board is needed to show Feature dependencies
- Every 2 weeks, the Agile Teams need to demo their integrated product in the System Demo meeting
- The ARTs each have a Program Backlog consisting of sequenced Features
- Features are prioritized using WSJF
- A Program Kanban is needed to manage the Features as they flow through
- 2 types of Features are needed: Business Value and Enablers
- The Release Train Engineer is needed to coordinate the overall ART activities
- The Product Manager is needed to talk to customers and build out the Program Backlog
- The System Architects is needed to ensure the structure of the solution follows well-known design patterns
- The Business Owner is needed to assume the business and technical responsibility for ART return-on-investment
- Design thinking is needed to help create desirable products
- Persona are needed to depict the different users of the solution
- Empathy Maps are needed to promote customer understanding
- Journey maps are needed to model the customer’s end-to-end experience
- Story Maps are needed to discover the Stories associated with common user activities
- Customer Centricity is needed to focus on creating positive experiences for the customer
- Market Rhythms are needed to help plan out releases
- An Inspect & Adapt meeting is needed at the end of each PI
- PI Roadmaps are needed to show the mapping of Features across 3 PIs
- Metrics are needed at the ART-level to inform outcomes, flow efficiency, and competency
- Solution Context is needed to ensure we are considering the correct execution environment
- Solution Trains are needed when multiple ARTs need to collaborate
- The Solution Train Engineer is needed to coordinate the overall ART collaborations
- The Solution Manager is needed to talk to customers and build out the Solution Backlog
- The Solution Architect is needed to ensure the structure of the solution follows well-known patterns
- Both future and current Solution Intent is needed to store, manage, and communicate what is being built
- 2 types of Capabilities are needed: Business Value and Enablers
- The Solution Backlog is needed to contain the sequenced Capabilities
- Capabilities are prioritized using WSJF
- A Solution Kanban is needed to manage the Capabilities as they flow through
- Solution Roadmaps are needed to show the mapping of Epics into future years for the specific solution
- Solution Demos are needed across each PI as cross-ART functionality is integrated
- A Pre-PI Planning meeting is needed before the PI Planning meetings
- A Post-PI Planning meeting is needed after the PI Planning meetings
- Metrics are needed at the Solution-level to inform outcomes, flow efficiency, and competency
- 2 types of Portfolio Epics are needed: Business Value and Enablers
- The Portfolio Backlog is needed to contain the sequenced Epics
- Strategic Themes are needed to connect the Portfolio to enterprise strategy
- Portfolio Vision is needed to describe the future state for the Portfolio
- Portfolio Roadmaps are needed to show the mapping of Epics into future years
- A Portfolio Kanban is needed to manage the Epics as they flow through
- Lean Budgets are needed in order to fund the value streams and not projects
- 4 Lean Budget Guardrails are needed to ensure judicious use of the funding
- Epic Owners are needed for shepherding the Epics across the Portfolio Kanban
- Enterprise Architects are needed for establishing the architectural constraints for the company
- KPIs are needed at the ARTs to compare against the Portfolio OKRs
- Metrics are needed at the Portfolio-level to inform outcomes, flow efficiency, and competency
- Development value streams are needed to help understand which Teams need to form ARTs
- Operational value streams are needed to help understand the overall high-level steps in delivering value
- Training for all SAFe roles is needed to ensure a basic foundation of knowledge
- 2 types of Enterprise Epics are needed: Business Value and Enablers
- Enterprise Strategic Themes are needed to convey overall enterprise strategy
- SAFe Program Consultants (SPCs) are needed to deliver training, launch ARTs, and accelerate the flow of value
- Communities of Practice are needed to be formed around specific roles and technology topics
- Shared Services Teams are needed to provide valuable centralized services to the other Agile teams
- – likely to have missed others
If you have the above situation, then just install SAFe as-is and your Agile transformation will be successful!
Stop the Madness of Installing SAFe As-Is!
By now you should have gotten my point that there is no situation where SAFe should be installed as-is. Installing SAFe as-is – just say no!
Cliff Berg, et al. in the wonderful book called Agile 2 – the Next Iteration of Agile states “The point is that the wrong way to add structure to Agile is by implementing a framework. A framework is a source of ideas and should be seen as nothing more.”
And to the quote above, I would add that every framework should come with a warning:
Installing this framework as-is is very unlikely to solve your context-specific needs.
Using a framework as a mental starting point may be valid, but even that feels like a stretch because it may be far removed from what is specifically needed. I have long been an advocate of “leading with empathy and understanding” instead of a framework.
In other words, hire an experienced Agile Coach (not a framework installer) to observe, understand, honor the past, and then and only then offer practices and approaches that have worked well based on their experience. While it may include small portions of a framework, the idea is to not start with the framework. Instead, apply targeted fit-for-purpose solutions from the Agile world.
Final point: The Coach’s ability to facilitate discussions where new Agile practices are invented is also a huge plus! In this way, the entire organization innovates their Agile practices and shares them across the enterprise for potential context-specific reuse.
Wrap
Stop installing SAFe as-is. Installing SAFe as-is leads to tremendous waste and solving problems that likely don’t even exist. More here.
Don’t believe me? Talk to the developers and folks in the trenches. You might be surprised!