Who Needs SAFe®? A Conventional Manager Discovers The Scaled Agile Framework

I spent 20 years as a "conventional" banker, and another seven as a conventional management consultant - before people started talking to me about post-conventional leadership.  It’s only in the last two years that I’ve encountered people passionate about the Lean and Agile movements.  And more recently, I’ve begun working closely with colleagues who are active in training and consulting around the Scaled Agile Framework SAFe®.

The founders of our company each have over 25 years experience in training and consulting to clients around progressive approaches to software and product development. I have had a chance to watch them train Lean-Agile leaders in the SAFe framework through several different forms of training, including the premium Safe Program Consultant 4.0 (SPC4) course.  I have been impressed by the quality of the thinking behind SAFe, and by the practical experience of watching these highly talented and experienced consultants share this work with others.  

I’ve now met many Agilists; all of those whose skills and insights I have inherently respected have said to me something like, “With Agile, it’s all about the people.” I think they meant that in bringing Agile to life in teams and organizations, the most fundamental principle is to care for and honour the people who do the work and who create the product, to respect their work in self-organizing teams and to give them the freedom and the encouragement to do their best work. The first value of the Agile Manifesto says, “We have come to value ... people and interactions over processes and tools.”  

My founders embody this principle in everything they do and in everything they teach - about SAFe and elsewhere. I have seen their teams of SAFe students gel beautifully, be clearly excited and proud about the work they were doing in their jobs using SAFe, and continue to maintain relationships, dialogue and mutual support in solving business problems together long after the course.  It is clear to me from these experiences that SAFe is entirely compatible with the “It’s all about the people” principle, which is indeed written into its own principles. By intention, especially at the team level, I see SAFe seeking to create great creative spaces in which teams can self-organise in the best traditions of the Agile manifesto. And I see evidence that a number of large organisations are using SAFe and getting results of which they are very proud, including creating highly attractive cultures - CapitalOne being only one example.

In the Agile world, we value people and relationships (individuals and interactions) over processes and tools. But if the human environment is sound and healthy, useful processes and tools help to get great work done. If SAFe provides intentionally for a great human context, as someone with senior management experience, I see that SAFe also provides many elements of practice that seem well thought-out and elegant as ways to attune the work of large numbers of people within Lean and Agile principles.

Some examples that most appeal to me include:

  • Focusing on the idea of value streams, as a framework for dynamic entrepreneurship and funding.  I love that this moves us beyond budgeting by silo or by the organisational department, and moves us toward a dynamic, incremental, iterative approach to spending and budgeting throughout the organisation.  This strikes me as a huge step forward toward an organisation-wide Agile mindset. 
  • Expressing strategic themes in the form of epics, which can be progressively broken down into capabilities, features and stories, creating a logical and connected process for flowing (in both directions) the strategic themes from board level to the work that creative teams do every day, dynamically adjusted and adapted with every iteration.  This process looks elegant, coherent and transparent to me. 
  • Forming Agile Release Trains at the program level, where 8-12 teams work together on common goals and related efforts. Attuning and aligning these teams’ efforts through cadenced Program Increments.  This approach strikes me as a brilliant way to allow multiple teams to feel connected, feel they belong to something larger, a context in which to ask for and to receive help from other teams, with cadenced opportunities to connect as an extended team with business vision and to set priorities and plans in a transparent and potentially inspiring way. Starting with one train and then growing from there seems to me to be a very workable strategy for scaling Agile practices.
  • Installing a regular cadence of Inspect and Adapt as part of the Program Increment rhythm, where the same cycle operates throughout the entire organisation.  This commonality strikes me as reinforcing a common, shared discipline of retrospection and the habit of continuous improvement.  That this rhythm and cadence exists throughout the entire organisation strikes me as highly supportive of shared Agile values.   
  • Release anytime: I can see that SAFe supports this idea, and indeed the idea of very frequent releasing through a DevOps culture.  I can see the value of this approach for increasing the Agility of units of the business well beyond software development.   
  • I’m very attracted by the “troikas” who provide leadership at both the program and the value stream level:  an engineer, who supports the whole Lean-Agile journey, an architect who supports the teams to attune to a common architecture and helps to create an adequate “architectural runway”, and the product/solution manager who helps to maintain a common integrated vision of the offerings being created for the market.
  • The approach to the active dynamic engagement of customers and business and product owners at all levels of the system, from the highest-level epic owners, to envisioning and managing the dynamic release of capabilities at the solution level, to active involvement in PI planning at the program level, to classic Agile product owner roles at the team level. I can see how this community of leaders, working together at many levels, could create a highly dynamic, rapidly responding system to serve customer needs brilliantly.

I am aware that SAFe can be controversial in the Lean-Agile community.  The criticisms I’ve heard centre around having too much structure, being over-engineered, creating too much overhead for people who conceive that the most important part of Agile occurs at the team level.

Critics seem concerned that with so much structure, the temptation to focus on structure and process instead of people becomes too strong.  I have seen critical presenters show the SAFe "Big Picture" on a slide without further comment as if the complexity of the concept was its own indictment. I can understand and resonate with some of these concerns.  

However, as one who has worked at senior levels in large organisations, I come back to the question: if, as a large organisation, we wanted to be Agile, with a firm commitment that we focus on people first, how would we attune large numbers of people to work elegantly together? We would need to answer such questions as: how do we do Agile planning and budgeting at a high level? How do we make collective decisions, allocate resources, and serve our customers, our shareholders, our suppliers, and our community well as a viable, integrated whole? Are there patterns of healthy practice that we can share throughout the organisation, and if yes, how do we share them? SAFe seems to me to provide constructive answers to those questions. I’m sure there are other ways to answer them, but, viewing it from my managerial history, SAFe appears to provide very sound, well-thought-through answers.  Adopting the framework as a form of a common language within an organisation appears to make a great deal of sense as a way to speed communication and collaborative working. It seems many large organisations have agreed. And I have watched some people whose talents and human values I admire take to it energetically.

So, who need SAFe? My answers include, as examples:

Executive leaders do

  • As a way to define and fund dynamic value streams
  • As a way to start with big ideas and bring them to life through daily releases from dozens to hundreds of coordinated teams

Who needs SAFe®? 10.jpg

  • As a Lean-Agile framework within which to free people to create and deliver their best work
  • As way to support hundreds to thousands of people to work together dynamically in the best spirit of the Lean and Agile movements

Business owners do

  • As a way to foster consistently rapid delivery of new products that meet customers' needs in a superb way
  • As a way to speed up product learning: release fast, fail fast, learn fast, succeed fast

Who needs SAFe®? 9.jpg

  • As a way to be in coordinated, dynamic daily conversation with multitudes of internal team members and customers

Scrum Masters and Agile coaches do

  • As a framework that prizes and leverages their skills - helping their teams find the freedom to self-organise around an elegant Lean-Agile toolkit, bringing their unique individual and collective strengths to bear to do great work

Who needs SAFe®? 8.jpg

Developers, testers, architects, business analysts do

  • As a framework that gives them freedom and creative space to self-organise, do great creative work and deliver amazing value every day
  • As a framework that allows them to share learning and delivery with a multitude of colleagues - often spread around the world

Who needs SAFe®? 11.jpeg

  • As a framework that gives them clear channels to fully participate in and contribute to the development and direction of the overall business

Learning more from experience every day, I look forward to the continuing adventure of working with leaders, whether they choose to adopt SAFe or not, to embrace Lean and Agile principles at scale. It seems to me that doing so is a crucial step in calling forward great organisations that create amazing value for customers - bringing all our inspirations to life. 


Like this post? Share it with friends