Using the Understanding of When SAFe® Is Heavy Is How to Use It Properly a Organizations Smaller Than It Was Designed For

September 27, 2014 — Posted by Al Shalloway

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

I’ve had a very interesting few weeks. At Net Objectives we’ve always put the customer first, even if this meant not offering a technology we were certified to teach. This has also made us unpopular with several of the certifying bodies that we’ve worked with.  The Scrum Alliance didn’t like when we said you needed Lean, LKU didn’t like it when we said teams were important, and I’ve been waiting for the day when SAI will tell us they don’t like that we say every approach has limits so therefore SAFe must have them as well.  This last one hasn’t happened btw and given they’ve had almost two years to do so, I’m figuring it won’t.  Just one of the many reasons I like working with SAI.

We never have (nor will) try to sell an approach just because someone wants it.   We always look to see when it is appropriate.  I’ve also long said that to truly be an expert in an approach you must know its limits – that is, where it does not apply.  This has always made me wary of the large numbers of people who do either Scrum or LKU Kanban but not both, but that’s another story.

In any event, I’ve had a couple of clients that don’t match the SAFe profile yet want to do SAFe.  In both cases, there is value in SAFe for several reasons:

  • SAFe provides an enterprise agreement on how work is to get sequenced and started
  • How to avoid shoulder taps
  • How to load balance teams
  • How to have teams work together

The first two are actually compelling but doing an overly heavy release planning event didn’t seem appropriate.  This is the case that got me into looking at what really is it about SAFe that can be heavy.  And, more importantly, when does it manifest itself.  See What Is It That Can Make SAFe® Heavy?

But now that I understand what is heavy about SAFe and when, it seems fairly simple to use the framework part of SAFe and not do a heavier than needed release plan.  This is actually pretty easy.

So what I’m left with is to avoid SAFe being heavy by adjusting the planning event to be lighter when the degree of planning and detail isn’t called for.  The 2-day planning event is just as much about socialization as it is about planning.   So the key is to adjust the degree and length of the planning.  Several folks might be left with a big “how?” but, since we’ve been doing Lean-Agile at scale for years, we’ve got lots of ways to coordinate teams.  See Mid-Scale Lean Agile Software Development

In both cases these conversations have created an opportunity to do SAFe in a lighter way than prescribed.  This enables us to get the holistic view of things without the heaviness.  This is important, as I discussed in an earlier blog: Insights at Agile 2014 Part 1 of 3

The bottom line is that anything can be misapplied (and typically is more than not).  What you want to do is get a partner to help you that is more attached to your needs than their solutions.   One easy way to tell who that might be is count the number of ways they have to help you. 

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