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 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.
|Lean Portfolio Managers||Executives who drive strategy, investment funding and prioritization|
|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|
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|
|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.
|Model Based Systems Engineering (MBSE)||
|Solution context or Product vision||
|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|
||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||
|Program Increment (PI) Objectives
|SMART (specific, measurable, achievable, realistic, time framed) Objectives|
|Continuous delivery pipeline
|Emergent design||Solution design resulting from collaboration|
||Types of backlog|
|Features (decomposed from Epics, capabilities or enablers)||
|Risk reduction (RR)||Risk mitigation|
|ART Sync meeting (SCRUM of SCRUMS and Product Owner Sync)||Weekly meeting of PMs to share progress on related projects|
|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)
- Go/No go
- Nonfunctional Requirements
- Portfolio, Program levels
Missing Concepts/Terms (there are a few key analysis concepts missing from SAFe)
- Current state analysis
- Data analysis and modeling
- 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 firstname.lastname@example.org or post a reply here.
5 thoughts on “SAFe® is Analysis: Translating the Terminology”
Great article Barbara; this is solid thought leadership material. I love the mapping and yes please send me a PDF copy.
Your comment about the BABOK from the IIBA being the industry standard analysis language makes me think. I think that we in the BA profession self-declared the BABOK to be an industry standard but that in and of itself does not necessarily lead to concurrence from other professions. I suspect the PMI-BA folks would claim their material serves to function as the “industry standard”. I believe that other professions such as the OMG claim their material is the book of record.
Regardless, the analysis you shared is terrific and a goldmine for the BA practitioner struggling to speak to Agile practitioners in their language.
Barb – thanks for taking the time to translate the SAFe language into meaningful chunks that
BAs can digest. This is a super helpful resource and it shows the value that Business Analysis brings to the organization.
thanks for your valuable information, please send me PDF format of this post
Hi Barb…great article…I would love a PDF version!`
I could not refrain from commenting. Perfectly written!
Comments are closed.