SAFe: Market Share Increase. Rapid Growth. What is the recipe?

Tweet

IMPORTANT: >>> References (bottom of page)

Some time ago, there was a webinar recorded by VersionOne: How to use SAFe® to Deliver Value at Enterprise Scale Q&A Discussion with Dean Leffingwell).   If you fast-forward to about 23 min, 20 seconds into the recording, you will hear the following statement: “…We don’t typically mess with your organizational structure because that is a pretty big deal…”

This statement somewhere puzzled me.  While graphic representation of SAFe framework is nowhere short of supporting organizational complexity, I was still under impression that organizational design improvements/simplification are included in SAFe teaching.  To me, an ability to influence first-degree system variables, such as Organizational Structure, is critical.  Without this ability, any attempt to improve organizational agility and system dynamics would be short-term and limited.  Even such important second-degree system variables, as organizational culture, values, norms, behaviors, policies, agile engineering practices usually bring limited results if organizational structure remains unchanged.

…But regardless of my recent new learning I admitted to myself that SAFe still remains a very successful (financially) and popular product that many organizations are willing to buy-unwrap-install….Fast forwarding…

---

 

Lately, there has been so much buzz in agile arena about scaled agile frameworks.  I just came back from Scrum Global gathering in Orlando, where I heard a lot of discussions about agility at scale and various existing agile frameworks that companies use.  Following Orlando discussions, I have seen a wave of email exchanges and blogs on the same topic, some of which involved seasoned organizational coaches and trainers.  I have noticed that there has been a lot of focus on SAFe (Scaled Agile Framework): opinions, comments, attempts to compare to other agile frameworks.   There are two things, in particular, that stroked me as odd:

1. It seemed that some seasoned coaches and trainers don’t explicitly state their views.  When I read indirect statements  or views, I remained wondering how a person really felt about the subject.
2. Among blogs and other posts that I saw, I was not able to see any discussions that covered aspects of SAFe that were of particular interest to me.

But before I go any further, here is my personal disclaimer:  I am neither SAFe practitioner, nor trainer or coach.  I have not attended a comprehensive SAFe course… However… I have studied/researched SAFe extensively on my own. And I do know some companies that have implemented SAFe (I have talked with some of their employees).  And I do know a significant number of individuals that have been trained on SAFe.  And I do know a handful of respected coaches that recommend SAFe.

Now, let me put “SAFe” topic to the side, for a moment, and shift gears to something else (we will all come back to SAFe in a minute):

I want to bring up the topic that has been a beat to death horse for awhile, for everyone who understands agility: the topic of tooling.

When it comes to discussions of agile tools, more experienced agile coaches have a long arsenal of arguments to use with their clients, prospects to explain why ‘agile tools’ are not most important for being agile.  Here some classic examples:

• 1st postulate of Agile Manifesto: “Individuals and interactions over processes and tools”
• “A fool with a tool is still a fool”
• “The best tool in Scrum is a whiteboard (or excel, at most)”
• “Agile tool is not a right solution for your deep organizational problem“
• “Never begin your agile education with tools. Always learn principles and concepts first”
• “Agile tool is a poor substitution for collaboration that you may never have. If you start exchanging information through a tool you will lose the benefit of a live discussion.  If you absolutely just introduce a tool, do it later in a process, when people gain sufficient amount of knowledge and experience”
• Etc, etc, etc…

We, as coaches, are never shy to express our strong views (sometimes, overly strong) that tools are NOT a good solution to organizational problems and NOT the best method (by far) to transform organizations.   And I am glad we are not shy about that.   This is why we are called Organizational Coaches – we look at organizations holistically.  For us, tooling is just a tiny fraction of a much bigger organization puzzle.

<SIDE NOTE ON>

But I still want to confess, with regards to tooling, so here is another personal disclaimer: over the last decade, I have been around and have gained a lot of experience with tools like JIRA, Version One, Rally and others…  I consider this as a personal ‘hobby’ but I know how to decouple it from daily work that I have to do as an organizational coach.  Over the years, I got to know some great software engineers that built the tools mentioned above.  I could probably easily pass for an in-house “agile tool expert” (that is if I decided to change my profession one day) and find a job that says something like this: “Looking for a strong agile tool expert to transform our organization to the next level. PMP certification is a huge plus.”.  Yes, sadly there are many job specs out there that sound just like this 🙁 .

On a brighter side, I could probably also leverage my ‘hobby’, and look at any agile tool, used by a team or a group of teams that claims “to do” agile, and in about 5 minutes find a handful of signs of serious systemic dysfunctions (just in a tool alone!).  So, there is actually some practical use of my ‘hobby’.  In any case, I think I have earned the right to say that I know very well what tools can and CANNOT do for you.  And this is why, I strongly stand with all other coaches that use the arguments I listed above.

<SIDE NOTE OFF>

 Now I would like to come back to the topic of SAFe and set the stage to my questions, by stating the following:

High Market Penetration of SAFe:

First of all, lets take a look at some relevant data that has been recently published on InfoQ, with the original source being Version One, 10th Annual State of Agile Survey: while still being a relatively new framework, SAFe has acquired a significant share of market place –23% , while demonstrating the highest rate of growth:  “…the largest increase from 19% in 2014 to 27% in 2015…”

 

My understanding of safety that SAFe brings:

I have heard various opinions about what went into thinking of the acronym “SAFe”: was it an intention to make it sound phonetically “safe” or was it just coincidental that the words Scaled Agile Framework that begin with “S”, “A” and “F”, made up SAFe?  I don’t know.  And I don’t want to speculate.

But let me share my understanding of what makes SAFe – safe:

• SAFe does not seem to be threatening to first-line management. Thanks to its first two layers (Team/Program & Value Stream) and abundance of processes and roles that are present in both, everyone can find place to work.  Probability of being misplaced or losing a job within SAFe is relatively low.  If we all recall, what happens with implementing basic Scrum, where teams are expected to become self-organized and self-managed, and where the role of Project Manager is not explicitly discussed, we (coaches, trainers) frequently have to answer the following question, usually coming from managers: “what now happens to my role?”  And of course, there are ways to handle this question properly and give good options to those who ask.  My point is that I don’t expect this question to be asked as frequently with introduction of SAFe.  Why?  Because SAFe seems to be a good way to harbor many existing management roles (role security).
• SAFe looks “homey” to senior management.  SAFe graphic is very rich in colors, objects, lines, layers, icons that represent roles, groups, departments, interactions.  At a glance, SAFe appears as a natural fit and a comfortable habitat for many existing organization constructs.  SAFe does not challenge/simplify existing organizational design; no hints to change/simplify reporting lines or flatten layers (de-scaling).  No need to have unpleasant conversations with employees (!).  Senior managers that are confident that their organizations are well designed and don’t need any major repairs, see SAFe as a safe way to try agility.
• SAFe does NOT explicitly compete with other agile practices. SAFe uses them all. In fact, a cute yellow smiley-squeeze-toy that many folks picked up in Orlando from SAFe kiosk, explicitly says: “SAFe embraces Scrum“. Indeed, at its multiple layers, SAFe diagram mentions Scrum, Kanban, XP,…and many roles, artifacts and ceremonies and iterations that support all these practices. And this, IMO, makes SAFe really safe, in a very special way: if Company X already uses, perhaps inconsistently, some agile practices, it is relatively safe, and actually convenient, for SAFe consultant to come in and say something like this: “we can help you retain most (if not all) of what you have adopted so far but it will be much better structured under the overarching umbrella of SAFe”.

 

My understanding of SAFe Partnerships and Strategic Goals:

Here, I am listing only the top few references that I found on-line.  But the list could be much longer if I spent more time searching.  I personally have attended a handful of webinars, where concepts of SAFe were presented, along-side with benefits of tools (by companies that hosted webinars).

Please, finish reading the post first and then come back to the links.

Choices and Partnerships by BIG CONSULTANCIES:

• With TCS
• With Deloitte
• With Accenture
• With BCG
• With UST Global

With TFS/VSTS:

• SAFE REPORTING ON VSTS
• Scaled Agile Framework: Using TFS to support epics, release trains, and multiple backlogs
• Implement Scaled Agile Framework® to support epics, release trains, and multiple backlogs
• Scaling Agile at an Enterprise level: SAFe and Microsoft Team Foundation Server

With Rally:

• Rally Portfolio Manager Highlights
• Scale Agile SAFe®ly
• 10 Things You Need to Know About SAFe 4.0
• 41 Things You Need to Know about the Scaled Agile Framework® (SAFe)

With Jira:

• Jira Align and SAFe
• Announcing JIRA Portfolio: View, plan, & manage initiatives
• Scaling agile in the enterprise with SAFe and JIRA Agile
• How do I setup JIRA and JIRA Agile for the Scaled Agile Framework?
• JIRA SAFE – THE EASIEST WAY TO MANAGE WORK ACROSS PROJECT, PROGRAM, AND PORTFOLIO

With Version One:

• Implementing Scaled Agile Framework® (SAFe®) with VersionOne
• Scaled Agile Framework® SAFe®
• Scaling Agile with VersionOne
• VersionOne Accelerates Enterprise-Scale Agile with SAFe® 3.0 Alignment

With Version One: Beware of “Trippe Taxation” Problem

Just to be clear for those that may not be as well familiar with these tools as I am (you don’t have to share my hobbies 🙂 ): each one of these tools now has complex “Strategic Layer” that sits at the top of a tools’ “tactical” layer (epics/stories, backlogs, sprints, releases, team views, agile boards, story/task boards, workflow management, etc, etc) – and it is used by a Project, Program and Portfolio Management.  At some companies, where I have consulted, each one of these layers usually has a manager (Project Manager, Program Manager, Portfolio Manager, respectively, etc), someone who is responsible for data collection and status reporting – just like it was without or prior to implementation of SAFe.  Tool complexity is great to offer a nice fit to an existing organizational structure.

<SIDE NOTE ON>

What is also not a surprise to anyone is that there are so many large companies that own tens of thousands of licenses for the above mentioned tools.  I consulted to a number of such companies and seen these tools being a “hallmark of organizational agility”.  Please note that very frequently “best practices of use”, even for agile tools, reside within departments like Control & Governance, PMO, and Centers of Excellence, where decisions about “what is best” are made in a vacuum and then are pushed down onto organizational domains that are thousands of miles away.

<SIDE NOTE OFF>

Here is another safety aspect of SAFe:

SAFe is very safe to client-to-vendor relationships  : it does NOT disrupt existing million-dollar (of course, depends on company size) contracts and license agreements between client companies and tool vendors.  It should be pretty safe, imo, for a SAFe consultant to come in and say something like this: “if you are using JIRA or Rally or Version One or any other tool that has Portfolio Management layer in it, it will be very complimentary to what we can do for you in terms of agile scaling”.   I think that the links that I have provided above suggest exactly that.

SAFe seems to be a great compliment and strategic alliance to some agile tooling companies that have gained a lot of  their own market share.  And it does not matter if JIRA and Version One and Rally or others, could be competitors to each other. They all seem to be great partners of SAFe (I will not speculate on exclusivity of relationships but based on the links above, there is probably none).

Now, after I brought to light some relevant market data, shared some personal views on what I consider as “safety factors of SAFe”  and gave a perspective on some possible strategic alignments that may exist between SAFe and industry leaders in the world of agile tooling, I would like to ask the following two (2) questions:

• First Question: Do you think that market penetration of SAFe and its adoption success could be attributed to a personal safety of companies’ managers, as I have described above?  Do you feel that ‘role security’ of first-level management in particular is a significant contributor to SAFe adoption rate?  I stress this last point because the role of first-level manager is in super-abundance today at many companies.
• Second Question: Do you think that market penetration of SAFe and its adoption success could be attributed to (at least in part) to its direct or indirect alignment with industry leaders that build agile tools?  Do you think that “SAFe + XYZ tool” produces a stronger compounded effect on organizations in terms of SAFe adoption, than SAFe applied alone?

---

Publications about SAFe, by Agile Manifesto Co-signers/others:

Also, as a reference, some experience reports about the Spotify “Model”: