SAFe's Answers to Our Inflection Points

April 14, 2015 — Posted by Al Shalloway

Early last year I wrote a blog that described what you must address at Scale - Not Doing SAFe®? No Problem. Not Doing These? Big Problem.  Last month i wrote a blog about questions that must be asked and answered when doing Agile at scale.  This blog puts the two together in describing how SAFe answers these inflection points, thereby enabling one to implement key aspects of a transition to Lean-Agile.  I'll go through each of the questions listed before, describing SAFe's answers to them.  If you didn't read the earlier blog, I suggest reading that first. 

Enterprise Wide

  • Are we doing an implementation or a transition?   SAFe is clearly about a transition even though people often refer to their actions as "implementing SAFe."  One cannot just take some courses, do a planning event and go. One has to change the role of management to being more leadership.  People do not need to be managed.  But creating vision and good eco-systems requires management.
  • At what level should we start? SAFe suggests starting at the program portfolio level.  This is often achievable, while starting at an enterprise portfolio level, while ideal, is typically not possible.
  • What should the pace of our transition be? SAFe doesn't discuss this except for the fact that the program must be all in.  But from the first steps after the decision to the initial planning event stage can be a matter of weeks or months. Our own experience is that a transition takes 1-4 years.  Less if good leadership already exists and automated testing is present.  More if respect and trust are not very present, too many projects require too many of the same people, and technical debt is very high.
  • How should we manage the transition? SAFe has many roles that will help with the transition.  The System Team and Product Management teams in particular.  SAFe puts the responsibility for success on leadership/management.  Net Objectives extension: Create a transition team whose responsibility is to coordinate the transition to SAFe.
  • What roles do we need to add, change or even eliminate? The key new roles SAFe suggests outside of the standard Agile roles are: Enterprise and program architects, product managers, release train engineers, system team, and product management team. Net Objectives extension: The RTE is responsible for making sure the content of the teams comes together at the right time.  This is implied by they being the uber ScrumMaster of the SoS of all of the teams.  SAFe somewhat has this be a team responsibility and the RTE merely coordinates this happening.  We have found that a higher view, explicitly responsible for the right pieces coming together at the right time is needed.

Enterprise Portfolio

Note: SAFe 4.0 has an icon mentioning Enterprise Portfolio but I don't know anything about what's coming. So I'll just mention what Net Objectives does now.

  • What is the enterprise budgeting cycle?  We recommend no longer than quarterly budgeting, or even a Beyond Budgeting approach.
  • How should we sequence the work items we’re going to develop across the enterprise? Net Objectives extension: Getting agreement at the portfolio level requires the use of minimum business increments and an agreed upon way of sequencing these.  These can then be sequenced through the use of an extended (proprietary) weighted shortest job first approach.
  • How are you going to make the work visible? Net Objectives extension: work should be made visible at the enterprise portfolio level in the same manner that SAFe makes it at the program portfolio level. 

Program Portfolio

  • What is the program budgeting cycle? Budgeting can be done one of two ways in SAFe.  One can do annual budgeting and implement the budget in chunks of 2-3 months (the program increments).  At the other extreme SAFe can budget a program increment at a time, although it usually recommends a longer roadmap. Net Objectives Extension: Program portfolios should be budgeted in the same cycle as the enterprise budgeting cycle.
  • How should we sequence the work items we’re going to develop in this program? Work items are organized into epics and then sequenced using weighted-shortest-job-first (WSJF). During the planning event features derived from the epics can be re-ordered according to business value.  Net Objectives extension: Decompose the epics into minimum business increments (MBIs) and sequence the MBIs with WSJF.
  • How will we budget and manage architecture and technical work items? SAFe suggests allocating a percentage of our capacity to technical work.  These are called architectural epics.  While not stating a percentage, it is common to see 20-30% being used.
  • How do we decide when to initiate work? Work is planned in 2-3 month increments in the program increment planning event. During this event work is scheduled into the upcoming sprints comprising the event. 
  • How will we manage the initiation of tactical work? Tactical work is work that comes in on a more frequent schedule than the planned for, strategic work.  It often comes from internal groups or some salespeople having short term opportunities.  Tactical work is often initiated via "shoulder taps" (i.e., a manager sidesteps initiative protocols and asks a developer to get something done).  SAFe requires all work that is to be done to be planned during the planning event.  Net Objectives extension: Tactical work of a certain size must be put into the normal planning cycle.  However, a certain amount of capacity can be set aside to implement tactical work or a convention whereby the tactical work is only done when it doesn't slow down the planned for work can be implemented.
  • How should we decompose our work? Epics get initiated from our strategic themes. These get decomposed into features which get decomposed into stories which are the main work items we implement. Net Objectives extension: Decompose Epics into minimum business increments (MBIs) and then MBIs into features and then features into stories.

Program Implementation

  • To what extent should we use Acceptance Test-Driven Development? Test-first is a mantra of SAFe development.  It should always be used.
  • What should our release planning cadence be?  These is no schedule for release planning.  While we develop on cadence, we deliver on demand.
  • How should we plan our implementation at the program level? Program level implementation is planned during the program increment planning event - curiously named Release Planning (curiously because it is not about planning releases).  This is a two-day event where all teams plan out their work over the next program increment in two-week sprints.
  • How should we organize our teams? There are two levels of organization.  The first is into trains, the second is into features.  Training comprise all of the people required to create the epics of a program.  Trains are composed of teams of 6-10 people that will actually do the work.  It is suggested that feature teams be used.  Feature teams are teams with the capabilities of implementing features on their own.  Otherwise, component teams may be used. In any event, teams should be working on only one feature, within one train, at a time.
  • How should we coordinate teams that must work together? Although teams have their own backlog, these are created at the same time as all of the other teams in their train. 
  • How will shared services work with the development teams? SAFe suggests that shared services participate in the planning event and should be periodically embedded into teams on the train when possible. Net Objectives extension: Use Kanban to manage the shared services as much of the work they do will be discovered during the program increment. In any event, shared services typically do work for other trains and even for those not doing SAFe, meaning they must be very Agile and cannot always have committed backlogs. 
  • How do developers work with ops?  SAFe suggests taking a DevOps approach. 
  • How will we estimate our work to be done? SAFe uses story points, planning poker to estimate the work and has each team's velocity be 8 times the number of team members (basically one story point a day of non-planning days). Net Objectives extension: Use Steve Bockman's team estimation and use past velocity per sprint (i.e., the number of story points implemented by the team) as the team's velocity.

Team

  • What methods will our teams use? SAFe suggests using an extended version of Scrum as its primary team method.  It has greater visibility and better test methods than classic Scrum.  While not having full explicit workflow, an emphasis on managing WIP (qualitatively in any event) and quality code (having at least automated acceptance testing and continuous integration) is suggested.  The approach is called Scrum/XP.  Kanban is now an alternative method when required (mostly for shared services).  Net Objectives extension: teams should use our new approach called Leanban.  Leanban is based on Lean while including the appropriate practices of Scrum, Kanban and test-first.  Leanban can be tailored to the context of the teams using it while still providing a consistent approach across the organization.
  • How should we develop our code? Test-first, continuous integration, automated acceptance testing and acceptance test-driven development are recommended.
  • How can we avoid the tradeoff between speed and quality? SAFe does not go into enough depth to answer this question.  This requires a solid understanding of design patterns a la Design Patterns Explained, refactoring and sustainable test-driven development in addition to the approaches suggested by SAFe.  

As you can see, SAFe answers most of the questions that we feel need to be answered.  Not answering them at the enterprise level is no shortcoming as one typically cannot start there until after significant progress has been made at the program level.  By understanding the answers to our inflection points, one can better understand both why SAFe can be effective and how to implement it as part of a Lean-Agile transition.

We are also in the process of creating a user group just for our clients and followers (and a few selected associates).   If you are interested, please ask to join.  No consultants please, this is just for our clients and practitioners.  As always, please contact me if I can be of any assistance for you or your company.

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.


Comments

Al, I like your points and most notably the distinction of "transitioning" to SAFe vs. trying to just "Implement" SAFe. Having just gone through what we labeled a major Transformation, SAFe became an active ingredient and catalyst to much of our cultural transformation.

That said, I just think we've abused this notion of "Transformation" where any time we move from point A to any new point - be it B, C or D - we concoct this idea of Transformation. God, my local deli just changed its ingredients in their egg salad sandwich and they called it a "transformation"!

In a sense the "transform" word, even though valid in most contexts, can be misleading and even scary to some executives. Although "Transition" is less sparkly and glamorous, in an attempt to change a company's way of thinking and how they work - introducing SAFe - or any framework or methodology for that matter - is truer to form and better described as a carefully planned transition and journey one must join.

The Hulk may be able to "transform" immediately after playing with some barium isotopes but we as people change over time by example, witnessing progress, and day to day successes along a well executed Change roadmap. This allows the "Change" to be accepted, ingested and adapted while allowing the Change itself, like SAFe, to evolve over time through real-world scenarios and targeted implementations.

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