New Early adopter or innovator? InfoQ has been working on some new features for you. Learn more

The Agile Coaches' Coach Shares Her View on SAFe

| Posted by Lyssa Adkins on Oct 06, 2014. Estimated reading time: 19 minutes |

This article conveys one agile coach’s journey coming to terms with Scaled Agile Framework™ (SAFe). Like pretty much everything I write, I’ll tell this story from my first-person perspective. I can’t help myself. I have an “I” perspective bias, which has me pay close attention to an individual’s internal experience, including my own. SAFe has an “ITS” perspective bias which is all about the external observation of a system or collection of things. We don’t always see the same world. More about the biases later.

When I first heard about SAFe, I was curious so I took a peek at the “Big Picture” diagram online. It gave me hives. It was just a little too much for me to take in and it looked way too much like those process and boundary diagrams I created when I was busy process-itizing software development as a Program Management Office (PMO) Director. Phrases like Program Portfolio Management were featured big and bold on the SAFe diagram; the very same words that I had unintentionally used to shackle people to a soul­killing process. I’m pretty sure one organization for which I was PMO Director is still struggling under the weight of the overly specified Sarbanes­Oxley (SOX) processes I was convinced we had to define in excruciating detail. You can probably tell that it brought back some not­too­pleasant memories. I have major karmic debt to work off there. Haunted by my past, I clicked the x at the top of the screen, and the Big Picture SAFe diagram disappeared. Whew! See? Gone. Now I could safely ignore it!

But I couldn’t escape it. SAFe kept coming up, most recently in our course, The Agile Facilitator, where every­so­often a student would ask, “Yeah, but how does that scale to our 150-person SAFe meetings?” 150-person meetings? You have to be kidding me! How many people do you think it takes to facilitate a 150­person meeting? I’ll give you a hint: more than one. Yet, this is exactly what SAFe was asking these Release Train Engineers to do! It became increasingly clear that the time for me to learn more had arrived.

Over the course of the next few months it would unfold that I would take a SAFe Program Consultant (SPC) course, as well as observe SAFe meetings in action. What I discovered is offered in this article; they are my thoughts alone, not an official “position” (no animals or corporations were harmed in the making of this article). I also need to disclose that I have not yet “done” SAFe. I am looking at it from the viewpoint of the discipline of agile coaching.

Direct Learning

I took the full SAFe Program Consultant course from the voice of SAFe itself, Dean Leffingwell. I wanted to hear it “from the horse’s mouth” as they say.

Based on the way the SAFe Big Picture looked to me, I walked into that class very concerned that SAFe would take away the teams’ creativity by “pre-chewing” the stories into requirements a la my project management days. I thought I might see the rebirth of “The system shall...” statements. I was also worried that SAFe would take away teams’ autonomy and reverse our still fragile belief in emergence; the diagram just looks so top down! These concerns put me on alert for anything that appeared to undermine the Agile Manifesto or the Scrum values.

A surprising thing happened in that class. Over the course of the next few days, the Big Picture morphed from being something ‘old-school’ that looked familiar, to something wholly unfamiliar, more multi­dimensional, and much more agile-expressive. Some of the old words were there, but they took on new meaning as we learned ways to help organizational managers decentralize decision-making and limit overall work-in-progress. These are the same things we espouse at the team level, just brought to a level where they can have positive systemic influence for all teams.

In class, I saw that the Agile Manifesto and Scrum values were alive and well and living inside SAFe. What Scrum gives to a team, SAFe gives to multiple teams working on the same product, or in the same value stream. When I later visited a large Fortune 500 company to see it in action, I witnessed a beautiful expression of these values in full bloom; far beyond what I had seen in my own work coaching groups of loosely confederated Scrum teams.

My direct learning yielded these thoughts about SAFe and the Agile Manifesto:

Individuals and interactions over processes and tools

SAFe maintains the safe haven for these precious individuals to collaborate within their intact Scrum teams, and at all levels of SAFe. I was skeptical about this, but then I saw a Release Planning session with 20­some teams and almost 200 people, and realized how SAFe is Scrum, just expanded to the program level. I became aware that Scrum itself scales beautifully.

Twenty­odd teams in the same room can do a wonderful job of simultaneous Release Planning. Going one better, SAFe upholds Scrum at this program level with the added structures of whole­ release­train cadence and synchronization, both of which get the product sprinting, not just the teams.

The people in the Release Planning meeting were not being told how to do their work, nor being given specifications at “The system shall...” level. The Product Manager ignited a fire of creativity and excitement by clearly articulating the vision for the product and disciplining herself to stay out of the “how”. It was music to my ears.

Then, the Release Train Engineer said, “OK, it’s time to plan for the next Product Increment, you all know what to do” and people jumped to action. I’m not kidding. They actually jumped out of their seats. The energy in the room went through the roof. Within 45 minutes, a couple dozen teams had draft release plans and were working out interdependencies with one another. The Product Manager was bopping around as teams asked questions, making sure they were aligned with the product vision. Each Product Owner was embedded with their team, explaining business intent and making tradeoffs.

The Release Train Engineer and one of the ScrumMasters facilitated the session with skill and full presence, attending to the many seen and unseen aspects that make a huge meeting clear, engaging and productive.

It went well because teams had the benefit of a well-facilitated meeting and full access to the product visionary. In addition, they made good use of technology and business managers, who were able to clear impediments on the spot. I only wish the loosely confederated groups of teams I coached in the past had access to this kind of “flow accelerant.” It was great.

Working software over comprehensive documentation

Since SAFe gets the entire product (or value stream) sprinting, working software comes out, integrated and done­done, on a regular cadence. Just like it does on Scrum teams, only now at the level of many teams. SAFe uses epics at the portfolio level, features at the program level, and user stories at the team level. No extra documentation required. Just the same structures we have always been using with Scrum, except that epics get expressed by the people who have their finger on the overall intent of the product/value stream (portfolio level), features get expressed by product management (program level), and user stories get expressed by the product owner and team (team level). Each level expresses what it best knows, closest to the source, and the voice of the overall product gets heard directly.

Customer collaboration over contract negotiation

A lot of people think about this Agile Manifesto statement as being about collaboration and contracts with outside customers or partners. That’s a worthwhile angle, but the angle I want to address is what happens within an organization.

An incredibly frustrating aspect of multiple Scrum teams in the same product area is the interdependencies between them, which can easily turn into interdependency gridlock. The cause of this is the way organizations organize. Most don’t yet organize in a way that lets us slice the Wedding Cake into thin slices of actual customer value. I can rail against that all day long, but in the meantime, interdependencies between teams flourish and can result in unexpressed contracts -- think of them as informal Service Level Agreements (SLAs) between teams. This offers life­saving mouth-to-mouth resuscitation for intermediary roles such as Business Analysts and Project Managers, as they run around coordinating these squishy SLAs.

What I observed is that SAFe brings all the players into synchronization on a regular Release Planning cadence, allowing teams to collaborate on the overall product(s) together. In doing so, the teams recognize interdependencies and work them out themselves, team­to­team. Interdependencies that could not be worked out were escalated to the technology and business managers right there in the room. This is an incredible short­cut. No Business Analysts or Project Managers (or ScrumMasters) need to navigate the organizational hierarchy to get these problems addressed over the course of many days or weeks. Instead, they get resolved as they are identified, giving everyone a clear view into the straight-line logic between interdependencies and trade-offs. Namely, interdependencies that cannot easily be accommodated are simply business trade­off decisions waiting to be made. With the synchronization of Release Planning, the people who can make those decisions are right there at hand. I saw such interdependencies get resolved as the product manager, aided by program-­level managers, made trade­off decisions on the spot.

Responding to change over following a plan

I haven’t yet seen evidence of this one in action, although I can imagine it. To do so, my horizon has to expand from the cadence of one or a few Scrum teams, to the longer cadence of a Release Train Product Increment. Just the same way that Scrum allows quick product adjustments at the border of every sprint, SAFe allows adjustments at the whole-product or value stream level at each Product Increment. And, adjustments still happen within each Scrum team during each sprint, as well.

Lean in the Lead

Perhaps one reason people assert that SAFe violates Agile values is that it focuses on Lean principles first and foremost, throughout an organization. It has a greater allegiance to an entire product sprinting, an entire business area ordering their work on business value, and an entire management team limiting how much WIP they put into an organization. SAFe simply gives more weight to Lean, which puts the focus on the product or value-stream rather than on teams.

At the same time, SAFe is 100% reliant on functional Scrum teams and their ability to live fully into the Agile Manifesto and Scrum values. There need not be an argument between Scrum and SAFe. It’s “both / and”. If the teams cannot deliver quality product within a timebox with regularity and sustainability, SAFe will not work. Period.

Just like Scrum, though, SAFe isn’t easy. It has some built-in assumptions and treacheries.

SAFe Relies on Agile-Acting People

SAFe completely relies on “agile-acting” people. All the way up, all the way down. The difference between a generative, full­of­energy Agile Release Train planning session and one where teams just come to “get their marching orders” cannot be seen on the page. The agenda for the meeting is the same in both cases. The difference is how much agility the people participating in the meeting already possess. For SAFe to work well, that level of agility and strong personal agile mindset needs to be quite high.

Could an Architect quash creativity by overly specifying architecture or coding standards in this meeting? Absolutely! Could a manager kill innovation by saying, “That HIP sprint demo is really great. It’s amazing what you guys created in just one Innovation week. The problem is that this means changes to our infrastructure. So, nice job but we won’t be putting it into production anytime soon.” Yeah, something like that could kill innovation pretty quickly.

With SAFe, you will likely have people participating who have never been on an agile team, never found the agile rhythm, the agile mojo. How in the world would they know which behaviors are agile-supporting and which are agile­killing? Going further, we want them to “be” agile, and SAFe needs them to “be” agile. That’s even a longer-term prospect. Possible, but a long road ahead and one that needs a guide.

SAFe is Likely to be Done Poorly

When I hear senior management say things like, “Scrum didn’t work, so now we’re trying SAFe” I get a chill up my spine. It causes me to think about the ways in which SAFe will likely be done poorly. Here are three:

Sheer veneer. Back to that manager who thinks SAFe is a substitute for Scrum. Managers who have this view clearly don’t understand SAFe, they probably didn’t understand Scrum, and here we go ‘round again. Because SAFe looks so familiar at the outset, it will be fairly simple to implement it with just a sheer veneer of understanding, housed within the same plan driven mindsets, with the end result not being agile at all. The nightmare scenario materializes: Product Owners turned into brainless minions and ScrumMasters into glorified gophers; top­down manipulation and pre­chewing the work resulting in a soulless human software factory. Could happen, but it’s not what SAFe is designed to do. That design intention probably won’t stop many organizations from creating the nightmare scenario, however.

Big means SAFe. Another pattern of SAFe done poorly arises with the unexamined assumption that just because we have a large organization we need SAFe to be agile. “Our organization is big, we need to scale,” they may say. Not necessarily so. Small clusters of teams very close to the business people may be far more effective, and may be all that some organizations really need. In these cases, SAFe would create process for process’ sake. If one, or a few, teams can get the job done, by all means stick with that; they don’t need to be “managed” within a SAFe process.

Brain-dead meetings. I have to be honest. Very few people I meet in my agile coaching classes have the facilitation skills it takes to pull off a large group meeting in a way that enhances creativity and provides the “flow accelerant” I mentioned earlier. By the time they leave class, they have many skills and techniques that will help but let me be clear here: facilitating a large group is an advanced facilitation situation. Experienced professional facilitators would find it challenging. In a poorly facilitated meeting, participants will be bored and disengaged which often leads to managers stepping in harder to “motivate” them or decide things for them. Managers, or the Release Train Engineer himself, may respond erroneously to the signals of boredom and disengagement, believing they have to step in because teams are clearly not able to “self-organize” on their own. All because the session is poorly facilitated.

Promotes bloat. Just because there are five layers of management today does not mean it has to be that way tomorrow. Just because there are 100 component teams for one product today does not mean that’s the best way to organize for a complex and ever-changing world. Perhaps these structures should be dismantled instead. Think back to that uninformed manager who thinks SAFe will cure the poor Scrum implementation. Her poor SAFe implementation would have the unintended consequence of propping up a bloated organizational design. I vote for letting those designs die a natural death, to be replaced by more modern, ecosystem-like organizational designs.

A Bigger Stage

None of this is different than before SAFe emerged. Managers and experts have always been able to energize creativity, or conversely, create zombie­like compliance for people on Scrum teams. The difference is that SAFe gives them a bigger stage on which to do so, and on a regular basis. If Scrum plays the community theater stage, then SAFe regularly plays Madison Square Garden. More spotlights, more people watching; greater possibilities for more impact and more danger.

I predict we will do SAFe with the same irregular amount of goodness and badness that we have done Scrum (and Agile at large) so far, only with higher stakes. People with agile coaching skills will likely have a job for at least the next 10 years, cleaning up and resetting things.

Back to the Biases

I mentioned at the beginning of this article that it was natural for me to write about my first-person experience learning about SAFe. I originally intended to write a more third-person, objective, maybe even somewhat scientific article about SAFe. I imagine I could force myself to do that, but every time I thought about it, I got an internal “Ugh!” It just seemed too daunting and I couldn’t see a way to even begin.

In contrast, the first-person version was a much easier undertaking because I have an “I” perspective bias. I see everything in the world through a window of the individual and the individual’s internal goings on, at least at first. In this case, I saw SAFe through my own eyes and my own internal experience. That was the most natural way for me to express it to you. You may have noticed that I even needed to personify SAFe to talk about it, as if it were a living, breathing being.

The “I” perspective is important. We’ve already discussed that managers evolving into a new state of agile-supporting mindsets are key, which is an “I” perspective issue.

SAFe comes from an “ITS” perspective bias. Again, an important view into what’s happening in an enterprise, and not the only one needed to achieve sustainable agility.

One perspective, or even two, is not enough. I must expand my awareness to include the other perspectives so that a more holistic, more complete view of the enterprise situation can come into focus. There’s also “IT” and “WE” to consider. Partial treatments are not nearly good enough.

Let me tell you about these perspectives and see if you can tell which one you are naturally akin to -- we all have one as our natural bias. These perspectives come from Michael K. Spayd’s work on Integral Agile and are much more fully (and objectively) articulated in the pre­release of his book excerpt from Coaching the Agile Enterprise. Integral Agile has been incredibly instructive for me as I try to get my arms around things like SAFe related to the complicated and complex aspects of agile in the enterprise. And, it explains why some people think SAFe will benefit agile, and others don’t.

Think of the perspectives as windows we look through. I’ve already mentioned the “I” perspective. It’s about an individual and what’s happening on the interior with them, inside themselves. When I think about enterprise agile, my first thoughts go to individuals; I often lament, “If only the leaders would evolve and shed command and control, agile would be great!”

Those with an “ITS” perspective bias are process thinkers at the whole systems level, and are attracted to things like theory of constraints and software development methodologies. They are into whole system measurement. If you find yourself saying some version of this, you might have an ITS perspective bias: “It’s the system that matters. If only we put people in a good system, they will be incentivized toward good behaviors and agile would be great!”

Those with an “IT” perspective bias are measurers of individual things: a behavior, a team, an engineering practice, or a product’s market share. They want to know if what we’re doing is working. Someone with an “IT” perspective bias may say, “If only we can get the metrics right, we can prove the results we’re getting from agile. Then, the right actions would spread like wildfire and agile would be great!”

Those with a “WE” perspective see systems of people. They are concerned with things like how groups and whole organizations build shared meaning, enact common values, express diversity and achieve a high performance state. Someone with a “WE” perspective bias might say, “If only we had a true, meaningful corporate vision, the teams would rally around it and nothing would stop them. Then agile would be great!”

One of these perspectives is not right and the others wrong. One is not even more preferred over the others. All are happening, all the time, and the limitation is that most of us agilists have a bias for one (or two); we don’t know that we’re not seeing the whole picture. For agile to be great, it will take thought and action from all four perspectives, yet most of us are looking only through one small window.

The SAFe conversation is commonly held from an ITS perspective orientation, since that is the underlying methodology it uses (like flow and process aspects of Lean). And, it’s not enough. In fact, no one thing is ever enough. No one thing covers all perspectives and matches the true complexity of the organizations we work with. All four perspectives are needed to match the complexity that actually exists, rather than reducing it to something easily explainable but utterly incomplete.

Let me bring in Rumi, a 13th century poet philosopher, to explain:

An ant hurries along a threshing floor with its wheat grain,

moving between huge stacks of wheat,

not knowing the abundance all around.

It thinks its one grain is all there is to love.

We have so much more to love in the agile world! Rumi urges us not to become too attached to one “grain”; one teacher or one way, or, in our world, one agile framework or one perspective. I urge the same. Rather, let us look out wider and farther. That’s what an Integral Agile perspective offers us. It’s why I am investing my time in training that will bring this to the agile community. I have hope that it will propel us into a conversation that features “yes, and.” Yes, SAFe AND Scrum AND leadership development AND corporate vision AND measurement AND...

Begin by noticing what window you naturally look through. Then, start to look out wider and farther. When we meet one another in that expanded view, we will engage in far less argument and far more collaboration, yielding more sustainable results for the organizations we are called to assist. Yes AND…

About the Author

Lyssa Adkins believes that Agile is an emergent response that helps us thrive in our ever-increasingly complex, changeable and interconnected world. She is a passionate contributor to the discipline and profession of agile coaching and has trained over 2,000 agilists in the knowledge, skills, and mindsets needed to coach teams and organizations to get full benefits from agile. In 2010, she authored “Coaching Agile Teams,” which is still a best seller four years later. Lyssa blogs on and, an important outlet for #WomeninAgile.

Rate this Article

Adoption Stage

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

I'm guessing the key success ingredient was Agile minded individuals at the top? by Paul Beckford

Nice article. Like yourself I have an 'I' bias. Also like yourself, this was born from my own prior experience of a process centric "ITS" perspective. I was heavily involved in TQM during the 1990's prior to discovering Agile.

Software is different I think from many of the endeavours organisations have traditionally engaged in, and due to it's creative nature and inherent complexity, I think an "I" bias is appropriate.

Other endeavours favour such a bias too. The ones that come to mind are the theatre, film, music etc. All highly creative, and all very dependent on individuals (over process).

If the lessons of both our experiences are the right ones; then the key success ingredient for software development is the people, especially ones in key positions. Where Lean and Agile come together for me is around the subject of Leadership.

My Hoshin Management training back in the day had a huge emphasis on the role of leaders. With the Japanese investing 10+ years to create good leaders!! In contrast, Agile has mostly been a bottom up phenomena, with mechanisms that you could argue are designed to "work around" poor leadership (I'm thinking about the role of Scrum Master as team protector here, based on the assumption of course that teams need protecting :)).

But what if teams didn't need protecting? What if the boardroom was more Agile then the teams themselves? What if the CEO was also the lead Agile Coach?

I see this as less to do with Scaling. As you point out scale for its own sake makes no sense -"Rightsizing" should be the goal, with a bias towards "small and human scaled". Incidentally small teams are more often the better option. Large teams are often a smell.

For me the SAFe discussion is really about where to start. Top-down or bottom-up? Given the huge influence of those at the top as facilitators - then clearly top down Agile is preferable where possible.

The real challenge I think is that in most organisations Agile minded individuals at the top just don't exist. Also many so called leaders are happy to impose change on others, whilst resisting change themselves. The consequence is the "misapplication" you describe. A crisis in leadership, leading to the now familiar fad cycle!

A much more thorny issue to address then which "process" should we use :)


Re: I'm guessing the key success ingredient was Agile minded individuals at by Lyssa Adkins

I love the article your posted. The story of your experience with leaders leading first at Teradyne is inspirational and, as we see, all too rare. It's not so much that I think an "I" bias is appropriate, it's just that the "I" and "WE" quadrants have not evolved as fast as the "IT" and "ITS" quadrants. It results in greater complexity in "ITS", like SAFe, and a need for greater complexity in "I" such as agile leaders doing their own inner development work but, as you say, we are not there yet. It's why I'm doing the work I'm doing to help evolve the "I" in Agile and it sounds like you are, too. Thanks for adding your article and story -- it makes this conversation much richer.

Great Review! by Peter Saddington

Lysaa, great review, very much in-line with my experiences detailed here:

I find a couple points of yours right on point:
- Requires agile-acting people - For sure. Gotta have people who understand it to execute it!
- Will potentially be executed poorly due to... a plethora of reasons. Always a risk here.

In many ways, SAFe could be executed well... if the maturity of the organizational infrastructure supports it or is seasoned in Agile.

A balanced view of an emerging approach to scaling Scrum by Robert Mead

Your thoughts reflect many of my own as well as some of my peers: There is something to SAFe. Yet, it's not been fully evolved at Version 3.0 and is not for every situation or firm. It's an excellent collection of Lean-Agile concepts that have been successfully implemented at some large firms. Even so, the methodology does not address the cultural aspects of adopting the SAFe. And, there are some technical aspects, like the notion of using "Normalized Story Points" in order to assess the performance of Scrum teams to each other that I understand are recognized as needing improvement, or replacement.

Whether a firm attempts to implement SAFe, Discipilined Agile Delivery (DAD), or Large Scale Scrum (LeSS) they will need to have mature Agile teams and not under estimate the level of cultural change to the business, if they hope to be successful.

Great balanced review by Gillian Clark

What a nice balanced review. I particularly like how you have linked the manifesto to SAFe/ I have written a similar one linking the principles of flow to the framework as I fundamentally believe SAFe is built on these principles at all levels.

Your latter points are all incredibly valid I shall just briefly cover a few of them:

- SAFe can be done poorly - you bet! So can Scrum, Kanban water fall - it's up to us as agile coaches and practitioners to make the practices work the best it can in the context they are in.

- you look for an ITS perspective. I understand the SAFe doesn't try to go too far outside IT, which I believe is correct so SAFe doens't try to be all things to all men. The Lean-Agile leaders can address your point "Yes, SAFe AND Scrum AND leadership development AND corporate vision AND measurement AND..." and ... fabulous change management - because with out it the implementation of SAFe will surely struggle.

I could write so much more - but I think you have it covered :-)

Re: I'm guessing the key success ingredient was Agile minded individuals at by Paul Beckford

It's not so much that I think an "I" bias is appropriate, it's just that the "I" and "WE" quadrants have not evolved as fast as the "IT" and "ITS" quadrants.

I know what you mean, yet at the same time I liked your use of the word "bias". As a whole our industry does have a bias, and acknowledging the prevailing bias is one way of promoting a more balanced perspective.

The conversation does often become "two valued"; "people" versus "process", "I" versus "IT", "WE" versus "ITS" etc. Getting beyond two valued thinking can be a challenge in itself :)

All perspectives are useful of course, the trick is selecting the most useful perspective for any given moment. This means being able to see things from several perspectives. A process perspective AND a people perspective, for instance.

As an industry we tend to be myopic, a lot to do with our history I guess, our assumptions, our beliefs and the prevailing management culture. Talking about biases openly is perhaps one way of addressing this historical legacy?

Interested in your thoughts.

Re: I'm guessing the key success ingredient was Agile minded individuals at by Paul Beckford

My last post was a bit woolly :)

As a concrete example of what I mean. You would never hear a journalist, a musician, or many other skilled professionals referred to as a "resource". Yet talk of resource and resources when referring to skilled practitioners is still common parlance in the software industry even now...

Why is that? And isn't that a clear sign of an industry wide bias that isn't serving us well?

Re: Great Review! by Lyssa Adkins

Peter -

Good to hear from you! Thanks for adding your article and voice to this conversation. We all have our work cut out for us as the late majority wakes up to agile. ;)


Re: I'm guessing the key success ingredient was Agile minded individuals at by Lyssa Adkins

We certainly have "advanced" more in the "IT" and "ITS" quadrants than the I and WE. No doubt. Each quadrant evolves at its own rate and I see that "ITS," in particular, has created more and more complexity (or created ways of working with more and more complexity) that have not been matched by our "I" evolution. So, a focus on "I" is certainly warranted. It's where I focus. And, at the same time, I am careful to remember that "I" is just one of four perspectives that are happening all the time. The difference is which ones we are paying attention to and, as an agile coach in complex situations, I am willing myself to pay attention to the wisdom and needs of all four.

Re: A balanced view of an emerging approach to scaling Scrum by Lyssa Adkins

Yes, indeed, Bob. Hence, why "WE" human technology is also important. Good to hear from you!

I/WE/IT/ITS perspectives by Tom Johnson

For those of us not already familiar with Spayd's work, the capitalization of these terms is misleading as it makes them look like acronyms. Is "IT" Information Technology? "ITS" == Information Technology Systems????

Re: I/WE/IT/ITS perspectives by Paul Beckford

Hi Tom,

I'm not familiar with the Spayd's work but it sounds interesting and useful. I tried googling but to no avail. Could you provide a link?


Re: I'm guessing the key success ingredient was Agile minded individuals at by Paul Beckford

Hi Lyssa,

My apologies for making you repeat yourself. After my last comment I read back and realised that you had already addressed the point I was making.

Thanks for persevering :) Yes "focus" is much better then bias :)

Your approach, and your desire to keep your own biases in check brings to mind Jerry Weinbergs buffalo bridle:

As a consultant it can be difficult to remember that the journey is not mine but my clients, and my role is to help them get to where they want to go.

Thanks for the reminder.


Re: I'm guessing the key success ingredient was Agile minded individuals at by Lyssa Adkins

Oh, how I love the Buffalo Bridle Law! I had never heard that, but will use it soon in an inspiration email. I especially love giving props to Jerry Weinberg - what a gift he has been to the agile world, and the world in general. Thanks for your perseverance with me, as well!!

Re: I/WE/IT/ITS perspectives by Lyssa Adkins

Michael has about a 100 page excerpt from his upcoming book, Coaching the Agile Enterprise, that he got special permission to release early for free. It's pulled down temporarily, but will be back up at, certainly before the end of the year. It's awesome stuff. Helps me not go crazy! If this piques your interest, consider adding yourself to the wait list for the next Deep Dive Study Group ($100 commitment deposit you get back if you attend all 4 sessions, so it's a deal!).

Re: I/WE/IT/ITS perspectives by Lyssa Adkins

IT = a thing (any "thing"). Doesn't stand for Information Technology at all (examples: a coding practice, a product's ROI)
ITS = a collection of things (examples: Kanban, SAFe)

I know, this can sound esoteric, but it's actually really eye opening when you start looking at the world in an Integral way. The Integral community is as big and as cool as the Agile community, but we don't know about one another, by and large. Michael is contextualizing Integral for the Agile world, much like I did with professional coaching. To learn about Integral directly, try this:

And, stay tuned to Michael's work bringing this into the Agile world.

Re: I/WE/IT/ITS perspectives by Lyssa Adkins

Huh...I thought I replied to this before but it does not seem to be here. So, apologies if two things show up.

Michael has a 100-page excerpt of his book, Coaching the Agile Enterprise, that he has gotten special permission from the publisher to release for free. It's the part that deals specifically with Integral theory and applying that to Agile. It is temporarily off our website (

Ways to learn more in the meantime:

Overview of Integral Theory (not specific to agile)

Deep Dive Study Group for Integral Agile. If you are interested in this at all, you may want to add yourself to the wait list. It's a steal - $100 commitment deposit that you get back if you attend all 4 sessions - purpose: create strong conversation groups through all 4 sessions)

Integral Agile Wizardry Bootcamp -- maiden voyage Dec 1-5. We just opened registration for this 48 hours ago and 12 of 24 spots have been applied for already. Check out the description. If you're truly in complex, enterprise situations as a leader or agile coach, this is for you.

Re: I/WE/IT/ITS perspectives by Paul Beckford

Hi Lyssa,

Thanks for the link. I knew what you meant, but it is nice to have a fuller explanation.

First thing to say is that this is a low bandwidth medium, which makes meaningful dialog difficult, so my apologies in advance.

Being "integral" isn't a new idea to Agile. Infact I can trace it back to my exposure to Lean in the 90's (although it wasn't called Lean back then, but I digress :)).

I mentioned Hoshin Management, that was an "integral" Japanese approach to leadership. The TPS (from which the western idea of Lean is modelled) included Hoshin and was an integral approach too...

For me Agile merely turned up the volume. In particular its focus on individuals, skill, uncertainty and nondeterminism for me were attempts to become integral and fill in the gaps. For me these represent the underlying values and principles of Agile. A world view if you like.

This root idea has been expressed many times since... The work of Dave Snowden for example, talks about Multi-ontological sense making - which advocates being integral, starting from the perspective of complexity:

Then there is The work of Devin and Austin with their wonderful book Artful Making:

Where they explore the ancient practice of making things (creativity), and ties between knowledge work and other creative professions like the theatre.

Not to mention Recardo Semler and his inspirational journey at Semco:

These are just a few of my favourites. All well established within the "Agile" cannon, yet seldom discussed, especially compared with something like SAFe :)

I take my hat off to you and Micheal and to all the others who persevere in repeating this message... But it is not new...

There are cognitive biases in play where as an industry we selectively choose the bits, that fit our preconceived ideas and ignore the rest. Again this pre-dates Agile. For example how many western "Lean" initiatives have taken onboard the full integral meaning of Hoshin Leadership as practiced by the Japanese?

There is a cultural bias at play (or cultural lens :)) which means that the "we' and the "I" perspectives tend to get filtered out. Leaving us with the "it" (SAFe) and the 'its" (Kanban, SAFe, Less,...).

This is the discussion I wanted to have. Why is that? And is there anything we can do about it? The Buffalo Bridle says that you can't take people where they don't want to go.... Well being integral seems to be a place that a lot of organisations have spent a lot of energy avoiding... :)

My worry with SAFe is it gives them yet another excuse not to go there :)

(rant over :))


Re: Great balanced review by Lyssa Adkins

Somehow, I missed your comment back in October. Thanks for it, and thanks for adding to the body of wisdom with your post.

How to introduce SAFe in a safe way? by Ben Linders

Great article Lyssa, thanks for writing it for InfoQ!

You mentioned that SAFe relies on Agile-Acting people. This in my opinion is true, but it is also where deployment of frameworks such a s Scrum and SAFe often fails.

If a framework is implemented top down with insufficient involvement of the professionals then chances are big that they will resist. Even when it's a good framework. Pushing a way of working upon people doesn't work, as can be concluded from my write-up on Alternative Approaches for Implementing Agile and from a recent debate on Adopting Agile: Should We Start with the Structure? between Dan Mezick and Mike Cottmeyer.

Lyssa: Do you have a suggestion on how you can introduce SAFe in a safe way? I.e. deploy SAFe in an organization in such a way that professionals will embrace it and adopt it to do their work better and serve the needs of the organization?

Ben Linders

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

20 Discuss

Login to InfoQ to interact with what matters most to you.

Recover your password...


Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.


More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.


Stay up-to-date

Set up your notifications and dont miss out on content that matters to you