SAFe® Is Not Popular Because of Great Marketing, It’s Popular Because It Fills a Need

September 27, 2014 — Posted by Al Shalloway

Note: this blog is part of the Series of Blogs on Scaled Agile, Lean and SAFe 

SAFe has erupted on the software development scene not due to fabulous marketing as its detractors have claimed, but rather due to the fact that it addresses a need most practitioners in large organizations have intuitively felt and most in the Agile community has denied. The patience of those wanting to become more Agile has well worn thin.  Being told they are “butters”, “shallow” or “just not doing it right” has just added insult to injury.  This blog discusses how SAFe is a manifestation of the Lean-Agile Framework.  Understanding the relationship between these two helps understand why SAFe works and how to adapt it to your needs.

One challenge many organizations have with implementing SAFe is that while it is a framework, it has many practices embedded in it.  It is often not easy to tell when the framework ends and the practices begin. The reason this is important to do is so you can make changes to the practices of SAFe as needed while not undermining the framework inadvertently. 

Be clear that in reality, the Scaled Agile Framework and the Lean-Agile Framework were developed independently of each other.  SAFe did not build itself on the LAF.  One of the reasons that Net Objectives has become a gold partner with SAI regarding SAFe and has several SPCs and an SPCT is that we recognized how SAFe was consistent with the LAF and was therefore following the laws of Lean-Thinking and the practices of Lean-Management and Lean-Culture.  This meant that SAFe was not an arbitrary collection of practices that its inventor found useful, but was based on the reality of the laws of software development.

Let’s take each item in the set of principles discussed in the prior blog and see how it is implemented in SAFe.  One should look at the Scaled Agile Framework big picture for guidance while reading this blog.

Work must be driven from business need and organized in a hierarchy of portfolio, program and team.  This one is pretty obvious as it is the distinguishing characteristic of SAFe and readily identified by the SAFe diagram with three horizontal rows – one for portfolio, one for program and the other for team.

Architectural and technical issues must have a representative equal to the business stakeholders of the organization. At the top of the SAF diagram one can see Epic owners and the Enterprise architect as the originators of work to be done.

Work must be decomposed starting with business capabilities until it is broken down into features.  This is perhaps our one point of disagreement.  SAFe uses a decomposition of themes -> epics -> features -> stories, while we start with business capabilities -> minimum business increments -> features -> stories.   However, our advanced approaches on prioritizing work at the portfolio end can easily be fitted onto SAFe so no conflict arises.

The product owner role must be expanded into a product manager and product owner role. This expanded role is necessary to manage the requirements at the portfolio, program and team level. 

There needs to be an enterprise and system architect roles to manage technical issues.  Architecture cannot be satisfied as a peer-to-peer discussion amongst teams.  SAFe specifically calls out these roles.

Someone needs to be responsible for managing the development value stream. The release train engineer (RTE) is an essential role in SAFe.

Teams must coordinate via shared backlogs and synchronize on a regular basis.  The program and team level structures implement this in one of many possible ways for this to be implemented.  However, at the scale for which SAFe is prescribed, this is almost always the best way to do it.

It is important to try to achieve cross-functional teams when it is economically viable. SAFe calls for cross-functional teams to the extent possible.  This is a good thing.  However, SAFe allows for any team organization at the team level that enables teams to work off of their shared backlogs while being in cadence to allow for synchronization.

Planning must deal with expected releases, risk management, dependency management and  how to coordinate work. This is exactly the intent of the release planning event in SAFe.

The proper work flow order, typically including some form of acceptance test-driven development, must be considered. SAFe does exactly this.  The suggested team practice in SAFe is called Scrum/XP to reflect the test-first nature of the workflow in the Scrum teams.

One must take a realistic approach and recognize where you are.  This includes addressing your ability to accept change, current state of technical debt, degree automated testing and degree of continuous integration. The fact that one should not need to take time to just run tests during the development cycle does not mean that one should preclude doing so if one can’t get everything integrated at the end of a sprint. SAFe is pragmatic here.  One must recognize that a transition is required from poor testing and/or integration practices to good ones.  But the fact that one is making the transition does not mean it happens instantly. 

Please discuss these on the Lean Systems Society Discussion Group.

Al Shalloway 
CEO, Net Objectives

Subscribe to our blog Net Objectives Thoughts Blog

Share this:

About the author | Al Shalloway

Al Shalloway is the founder and CEO of Net Objectives. With over 40 years of experience, Alan is an industry thought leader in Lean, Kanban, product portfolio management, SAFe, Scrum and agile design.



        

Blog Authors

Al Shalloway
Business, Operations, Process, Sales, Agile Design and Patterns, Personal Development, Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Cory Foy
Change Management, Innovation Games, Team Agility, Transitioning to Agile
Guy Beaver
Business and Strategy Development, Executive Management, Management, Operations, DevOps, Planning/Estimation, Change Management, Lean Implementation, Transitioning to Agile, Lean-Agile, Lean, SAFe, Kanban, Scrum
Israel Gat
Business and Strategy Development, DevOps, Lean Implementation, Agile, Lean, Kanban, Scrum
Jim Trott
Business and Strategy Development, Analysis and Design Methods, Change Management, Knowledge Management, Lean Implementation, Team Agility, Transitioning to Agile, Workflow, Technical Writing, Certifications, Coaching, Mentoring, Online Training, Professional Development, Agile, Lean-Agile, SAFe, Kanban
Ken Pugh
Agile Design and Patterns, Software Design, Design Patterns, C++, C#, Java, Technical Writing, TDD, ATDD, Certifications, Coaching, Mentoring, Professional Development, Agile, Lean-Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Marc Danziger
Business and Strategy Development, Change Management, Team Agility, Online Communities, Promotional Initiatives, Sales and Marketing Collateral
Max Guernsey
Analysis and Design Methods, Planning/Estimation, Database Agility, Design Patterns, TDD, TDD Databases, ATDD, Lean-Agile, Scrum
Scott Bain
Analysis and Design Methods, Agile Design and Patterns, Software Design, Design Patterns, Technical Writing, TDD, Coaching, Mentoring, Online Training, Professional Development, Agile
Steve Thomas
Business and Strategy Development, Change Management, Lean Implementation, Team Agility, Transitioning to Agile
Tom Grant
Business and Strategy Development, Executive Management, Management, DevOps, Analyst, Analysis and Design Methods, Planning/Estimation, Innovation Games, Lean Implementation, Agile, Lean-Agile, Lean, Kanban