SAFe® is Analysis: Translating the Terminology

SAFe® (the Scaled Agile Framework) is all about business analysis but it never uses the word “analysis” or has any role for analysts. This blog post offers a translation guide of SAFe terms into their corresponding analysis terms. (Skip to Guide)

A Little History

Agile software development has been promoted as the answer to IT development backlogs and delays for over a decade and has proven to be useful in creating software products for many organizations. But as many teams and organizations have tried to “become more agile”, most have had only limited success.  Many manufacturing, healthcare, and financial services companies are continuing to struggle, not getting the benefits expected from this adaptive, change-driven approach to design and development. As a business analyst, I have always been frustrated by the lack of attention to business analysis in agile. The creators of agile discounted (or completely forgot about!) the value of business analysis when agile approaches were originally defined. Development professionals felt a development team working directly with a business product owner could create useful products. (I’ll leave the discussion of why this doesn’t work to another article.)

SAFe®: The Scaled Agile Framework

After ten years of trying to make agile work, what had to be learned, as it did with traditional waterfall approaches, is that analyzing business needs and considering alternative solutions before coding is not only valuable, but essential to the success of a software development effort. Now agile enterprise frameworks like SAFe® have been created to fill the analysis gap in the original agile approaches. www.scaledagileframework.com

SAFe offers a structured, top down approach to strategic analysis, prioritization, and assignment of work to agile development teams. Unfortunately, the creators of SAFe invented new terminology and new roles to describe strategic and multilevel analysis rather than using industry standard analysis language –  IIBA®’s BABOK® Guide (International Institute of Business Analysis; A Guide to Business Analysis Body of Knowledge. www.iiba.org.)

SAFe attempts to describe a step by step recipe for business analysis starting with a high level strategic plan (using epics and strategic themes), decomposing business capabilities, identifying technical architecture needs, prioritizing and then building software. I am impressed that the creators of SAFe would attempt to define a methodology (although they would never use this word) for a very complex, multilayered and ever-changing process. When IIBA’s BABOK Guide coined the phrase Enterprise Analysis in 2004 it took several years before people began to understand what we meant and began to use the phrase to describe high level analysis which must be done before beginning work on individual projects.

SAFe Terminology

SAFe terminology is built around a train analogy. There are Solution Train Engineers and Release Train Engineers and the ART is the Agile Release Train (a team of Agile teams). According to the Scaled Agile Framework, the trains carry the features through the process and if a feature misses one train it can catch the next one. The train analogy doesn’t carry all the way through because there are also roadmaps and runways.

It’s a Foreign Language!

To describe how SAFe uses organizational goals to drive product development work (and who should be involved) SAFe uses new processes and roles (you’ll recognize some terms from Lean). The SAFe transformation roadmap recommends training everyone in your organization to learn this new, foreign language of release trains and epics.  This is one way of trying to transform an organization – require it to work in a different language with different processes. I like the focus on analysis from a high level in the organization, tracing down to individual development teams but am not sure about the foreign language.  Why do we need a new set of terms?

A Translation Guide

The tables below are not intended to teach SAFe but rather to help translate the language. I have found it useful to align SAFe terminology with words and phrases known in the BABOK Guide. The human brain learns new information by attaching it to something we already know. Linking SAFe terms to existing analysis knowledge may help with learning.

Roles Translation

SAFe Roles	Traditional Roles
Lean Portfolio Managers	Executives who drive strategy, investment funding and prioritization
Epic Owner	Project sponsor. Person who funds and champions the creation of a solution.
Solution Train Engineer (STE)	IT Director or Manager. Oversees large development efforts with multiple release trains.
Solution Train, Release Train (RT), Agile Release Train (ART)	Development teams working on different components of a solution.
Release Train Engineer (RTE) (acts as Chief Scrum Master for the Train)	Project manager, Business analyst, or Facilitator
Product Manager (PM)	Business domain SME responsible for product marketing and product strategy.
Product Owner (PO)	Business domain SME embedded with a team; responsible for prioritizing product features, managing product backlog, establishing acceptance criteria. PO reports to Product Manager. Some organizations use business analysts who are domain experts in this role.
Product Owner proxy	Requirements or business analyst who represents the PO on a remote team
Business owners	Business domain SMEs, stakeholders
System architect-engineer	Systems analyst, systems architect, enterprise architect
Team Scrummaster	Project manager or delivery manager

 

Terminology Translation

 

SAFe Terminology	BABOK Guide Terminology
Framework	Methodology or Process
Epic, Capability	High level business need or requirement
Epic roadmap and Strategic themes	Strategic plan, Strategy analysis, Enterprise analysis, High level business objectives
Business Case/Financial Justifications
Lean business case (for an epic)	Business case
Outcomes hypothesis, continuous value	Expected benefits, business value
Epic outcome hypothesis statement	Statement describing the desired functionality, expected value, measurable results and nonfunctional requirements.
Opportunity enablement (OE)	New business opportunity value
Economic framework	Cost benefit analysis
Non-economic based prioritization	Prioritization based on intangible benefits
Lean budgets	Budgeting based on value streams rather than projects
Analysis Techniques
Research resources and methods, continuous exploration	Elicitation techniques
GEMBA walk (Japanese concept of going to the real place)	Observation or job shadowing
Feature decomposition	Functional decomposition
Feature decomposition patterns: (e.g. workflow, business rules, data methods, use case scenarios)	Decomposition methods (e.g. bottom up, top down, data driven, sequential)
Continuous exploration, Collaboration and research synthesis	Requirements analysis and design
Program Increment Planning (PIP) – A 2-3 day face to face workshop to get agreement on vision, scope, requirements, priorities, design, and development plans using techniques like clear problem definition, root cause analysis, Pareto analysis, brainstorming, dot voting.	Project kickoff Scoping workshop Requirements workshop
Model Based Systems Engineering (MBSE)	Requirements modeling Business modeling Data and process modeling
Solution context or Product vision	Context diagram Solution or Product scope Future state
Alignment (epics should drive backlog items)	Traceability
Weighted Shortest Job First (WSJF) shorter duration and higher cost to delay	Quick wins
Set-based design	Considering alternative solutions during design
Deliverables/Artifacts
Architecture runway Enabler (build up the runway or extend the runway)	Technical requirements for code, databases, hardware components, or infrastructure that are needed for the development of business features
Program Increment (PI)	A solution or part of a solution that supports a business program.
Program Increment (PI) Roadmap	Product or solution roadmap Release plan with release dates Project schedule Phased implementation plan
Program Increment (PI) Objectives	SMART (specific, measurable, achievable, realistic, time framed) Objectives
Continuous delivery pipeline Continuous exploration Continuous integration Continuous deployment	DevOps
Emergent design	Solution design resulting from collaboration
Requirements
Portfolio Program Team	Types of backlog
Solution Intent User Stories Enabler stories Improvement stories	Business objectives and requirements Solution Requirements Functional Requirements
Features (decomposed from Epics, capabilities or enablers)	Backlog items with business priority Stakeholder requirements
Risk reduction (RR)	Risk mitigation
Processes/Ceremonies
ART Sync meeting (SCRUM of SCRUMS and Product Owner Sync)	Weekly meeting of PMs to share progress on related projects
Capacity Allocation	Percentage of time allocated to the project work by a resource Project scheduling
Release on demand	Deployment as scheduled by business (versus regularly scheduled releases)
Learning cycles, cadence	Sprints or iterations with retrospectives
Big up front design (BUFD)	Waterfall approaches
Portfolio Kanban	Portfolio or program management

 

Common Terminology (there are a few existing terms used by SAFe)

• Solution
• Go/No go
• Nonfunctional Requirements
• Capability
• Portfolio, Program levels
• Team

 

Missing Concepts/Terms (there are a few key analysis concepts missing from SAFe)

• Current state analysis
• Data analysis and modeling
• Glossary
• Interface analysis
• Requirements reuse
• Post implementation assessment

Learn the Language

SAFe lays out a process for enterprise analysis which is thorough and will result in opportunities for deep analysis at both the enterprise and product levels. It includes many great analysis techniques, most of which have been successfully used for years by business analysis professionals. I hope organizations which embrace SAFe are successful in transforming their businesses, but I fear this is another methodology, like RUP (the Rational Unified Process) which will flame brightly and then die because it focuses too heavily on new language while failing to grasp the complexity of analysis and the need for professionals who are experts in helping organizations think about their true business needs. For now, business analysts and project managers must learn this new language and adapt their existing practices to operate in this new environment (until the next silver bullet comes along!).

If you would like a copy of this blog post in a PDF format, send me an email message at [email protected] or post a reply here.