This statement somewhere puzzled me. While graphic representation ofSAFeframework does not shy away from supporting organizational complexity, I was still under impression that organizational re-design is included in SAFe teaching. To me, just like to any organizational coach or system design consultant, who helps companies with improving organizational agility, the ability to influence first-degree system factors and variables, such asOrganizational Structure, is critical. Without this ability, any attempt to improve organizational agility and system dynamics would be short-term and limited. Even such importantsecond-degreesystem 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 had to admit to myself that SAFestillremains a very successful and popularproductamong many large organizations. …And at this point, I would like to refer the reader, to my original post below….

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 are in 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 strike me as odd:

It seems that some seasoned coaches and trainers don’t explicitly state their views. When I read indirect statements or views, I continue wondering how a person really feels about the subject.

Among blogs and other posts that I have seen, I was not able to see any discussions that cover aspects of SAFe that are 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 significant number of individuals that have been trained in SAFe. And I do know a handful of respected coaches that recommend SAFe. So basically, I understand SAFe beyond just knowing how to spell it 🙂 .

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, most experienced agile coaches have a long arsenal of arguments to use with their clients, prospects or less seasoned agile enthusiasts. 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“

“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 live discussion. If you absolutely just to 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) about tools, NOT being a good solution to organizational problems and NOT being 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. And personally, I never heard organizational coaches disagree too much about the bullets above: we are all very much on the same page, we stand together on this, and we cannot be fooled.

<SIDE NOTE ON>

But I still want to be very transparent about myself, 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 have to do an organizational coach. Over the years, I got to know some great software engineers that have built the tools mentioned above. I could probably easily pass for an in-house “agile tool expert” (that is if I choose changing 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. You must also have a valid H1B Visa 🙂 ”. 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. So, 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>

Here is my conclusion: “It seems that organizational design experts, and system thinkers, change agents, agile coaches/trainers are pretty comfortable to, strongly and openly, state their views, in cases, where they feel they are stating the obvious – for example, about tooling.” Let’s hold on to this thought for a moment.

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 as “safe” or was it just coincidental that the words Scaled Agile Framework that begin with “S”, “A” and “F”, respectively, made up SAFe? I don’t know. And I don’t want to speculate. But let share my understanding of what some more obvious safety factors of SAFe are. But again, this is my view only:

SAFe does not seem to be threatening to first-line management. Thanks to its first two layers (Team/Program & Value Stream) and abundance processes and roles that are present in both, everyone can find place to work. Other words, the degree of fear about being misplaced or losing a job 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, but this is not my point. 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), although, perhaps under different naming convention.

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. There is no explicit invitation to significantly 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”. Other words, SAFe consultant does not have to worry too much about upsetting people of Company X, by making them give up what may have grown an attachment to – they can keep it all. Effectively, in my mind, SAFe acquisition does not have to translate into workforce/practice reduction. To me it seems to be a pretty safe offering.

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.

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 Layers that sit at the top of tools’ “tactical” layers and constructs (epics/stories, backlogs, sprints, releases, team views, agile boards, story/task boards, workflow management, etc, etc) – and they are meant for Project, Program and Portfolio Management. At some companies, where I have consulted, each one of these layers typically had a manager (Project Manager, Program Manager, Portfolio Manager, respectively, etc), someone who was responsible for data collection and status reporting – and that was without or prior to any implementation of SAFe (or any other scaled solution). Tool complexity alone was sufficient to offer a nice fit to an existing organizational structure.

<SIDE NOTE ON>

What is also probably not a surprise to anyone is that there are so many large companies out there that own tens of thousands of licenses for the above mentioned tools. I have been to a number of such companies and seen these tools being a “hallmark of organizational agility” to too many people that understood very little about true 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 Excellenc, where decisions about “what is best” are made in a vacuum and then are cascaded down to organizational domains that are thousands of miles away.

<SIDE NOTE OFF>

So, here is another safety aspect of SAFe that probably belongs to the previous section of my post but I will keep it here:

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 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.

All in all, SAFe seems to be a great compliment and strategic alliance to some agile tools companies that have gained a lot of their own market share over years. And it does not matter that 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 may not be any).

Now, after I brought to light some relevant market data, shared some personal views on what I consider as “safety factors of SAFe” (some people may see them as true benefits 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 and make one (1) small request:

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?

Third – Request: I would like to respectively request from my colleagues, coaches and trainers, when they talk about any topic (in this case, SAFe is the topic of choice, but it could be anything else), to be more open-minded and clear in their views. For example, if someone sees the same system relationships as I described above, and he is comfortable sharing his strong views about tools, would it not be reasonable to expect the same person shares his explicit views on related frameworks? And the opposite should be true too: if there is no comfort to explicitly discuss frameworks, why then be so adamant to state your views on tooling 🙂 ?

The last request, is an invitation to system thinking 🙂 .

I hope this post was safe for everyone to read 🙂 . Feedback is highly appreciated from everyone who has a view.

Related Publications about SAFe by Agile Manifesto Co-signers and others:

Open Space In one of the previous blog posts I explained the team-based conference and in another post the Conference Review Bazaar. During the conference we had an Open Space running in parallel with the conference and the Open Space information is collected in this post. What is an Open Space? Open Space is a […]

Conference Review Bazaar In the previous blog post, I introduced the second iteration of the team-based conference concept, which ended with a Conference Review Bazaar. This post collects the output of the Bazaar. How does it work? At the end of the conference, the teams get together in their team space and they have an […]

Team-based Conference - Iteration 2 It is already two weeks ago now… the 2017 LeSS Conference in London. I’m still missing the discussion, my team, the wine, the people, the weather. Well… not the weather. It was wonderful, I enjoyed it thoroughly and hope and think the other people did too! One thing I considered […]

How Most Agile Transformations Start Most of the Agile transformations I have witnessed have started like this: First, a company raises a strategic initiative on so-called Agile implementation. A large budget is allocated and a tender is arranged to purchase Agile coaching services from companies on the market. Then employees are trained, and the pilot teams start working. However, they immediately stall, […]

When it comes to taking a whole-product focus to scale agile with Scrum, LeSS (Large Scale Scrum) shines. As an agile product coach, LeSS resonates with me with regards to it’s focus on product, smart use of the Product Owner, reliance on feature teams for product requirements clarification, guidance on smart backlog management, use of […]