SAFe does not equal Safety

So I am working with a client that has decided to implement SAFe across its teams. They want to make their management of multiple applications easier. I have no doubt that from their perspective it is well intentioned. They do not understand it fully and the non inquisitive ‘coaches’ they have hired have no problem imposing it. And this is why I hate SAFe (sorry rant for a bit).

It really has nothing to do with having good ideas. SAFe has lots of them (I wish they gave credit to all those they pulled from – most of their, if not ALL their thoughts are not original.) They have plenty of good ideas baked into the framework. What kills SAFe from a safety standpoint is how much it is a practice mandatory approach. They talk about principles (I’ll get to one that I think is misused momentarily), but in the end, when people they certified execute this stuff, it is all about practices and implementing as stated.

So I have a big qualm in how transparency is described. That principle is used in how management can look into a team. No problems there. So what about the reverse? Can a team know why a decision was made by a product owner/manager or other stakeholder? This is usually not very clear and favors not letting a team know; it is presumed the external authority is more wise than the team.

I know, you’re thinking what is the big deal… Well I am working with an organization that tried SAFe a few years back and dumped it as it lowered its ability to release on demand. It has some minimal ‘gates’ it has imposed; it’s a government organization so it needs some for compliances external to the organization. Yet here comes SAFe and here is how it will do things. The consultants have no inquisitive mind about what is in place currently. When they decide to implement something, they also don’t ask what teams are currently doing. They plough ahead with what is mandated by SAFe.

Given I was asked to coach coaches (that were recognized as being too much by the book), I find it interesting how unresponsive they are to different perspectives on how SAFe ideas can be implemented. We’re going fully virtual, they planned to set up WebEx breakout rooms by team for PI planning. I pointed out that if teams could independently plan in their own room, then we have no need to ‘scale’, perhaps the breakout rooms should be set up as teams identify dependencies. This was brushed aside. Same for how POs should interact with teams. I expect coaches to recognize the need for adaption and to listen to feedback.

Unfortunately, most SAFe consultants (BTW, technically I am one – so disclaimer) seem to not consider the context of the organization, the work systems in place, the actual organizational context that is calling for scaling, and/or the various needs of teams. Why not? SAFe subserves this to the needs of its system of operation.

If you want to implement SAFe successfully, first consider organizational context. Skip their ‘patterns’ and implement the minimal elements you think you need and add or reduce elements on what you discover.

Second, think about the teams you are asking to change their work patterns. Some will go willingly; some won’t. This feedback is a gift, not a pattern of stubbornness to overcome. Perhaps what you perceive as an ROI isn’t as good as what they are offering. Skip the sales message, learn why they think their ROI is what is needed and how can fit into it.

Third, quit treating teams as people you can’t entrust with organizational decisions. This happens predominantly with two things at play: 1) there are incentives to not play nice and 2) the overall organizational goals are not clear and prioritized.

And that brings me to the last point… If at any time you feel you need to do a sales message, ask yourself why. SAFe seems reliant on ‘selling’ its importance. It’s part of the training for god’s sake… If the need is not self-evident, one should think of why an approach is being pushed. I’m not for not using it, but more for understanding true needs and letting it guide us.

See the Scaling Manifesto for more understanding…

Without these considerations, SAFe will not bring safety, something it proclaims,

A Principle for When Not to Estimate

Based on a prior post, I was ‘asked’ to extract this into a generalized principle. (I invite you to read that in full, so you understand the context.)

Of course, one has to open your mind that the value of estimating has to be questioned in this circumstance and what you are trying to accomplish with estimates and how they may or may not contribute to your work. And I would be remiss not to mention 3 things:

  1. My push on the #noestimates tag is not one of #neverestimate; on the contrary, I am interested in circumstances where estimation may need to improve OR it may need to be ditched to increase value production. I would never advocate to never estimate under all circumstances, yet at times estimation may be wasteful and should be eliminated. Depending on risk understanding, one may absolutely need to estimate. The more potential (in terms of probability and impact) for loss of life or loss of money, the more need to estimate. I do have a keen interest in when estimation may not be needed though beyond just dropping story points.
  2. If you decide to apply this principle, also determine the circumstances and how you would detect that perhaps this principle doesn’t apply in your context. Ask yourself, how does this apply? What will tell me whether I applied it incorrectly, and lastly what possible paths should I take to rectify the situation?
  3. Lastly, this whole set of arguments or debate is very binary. (I’ve only ever seen actual dialog on the topic at Agile Dialogs.) #nobinary is something I advocate on a variety of subjects and you can learn more about how to drop binary thinking and contribute to interventions at Agile Brambles (an evolving site). If your mindset is one where you only see your point of view, then you may find thinking through the paths on the site fruitful.

OK, onto the principle….

When the estimate is not going to be used, regardless of how quickly you can produce it, don’t create one.

Looking back at my context briefly, the old way was to estimate all work that came in and then regardless of the answer, we did the work.  This delayed the start of the work and actually digging into really understanding it by doing it. It doesn’t matter whether you are using a super sophisticated model or a simple guess. In my case it at a minimum delayed work by a week and in some cases more. From a any form of value production standpoint (like weighted shorted job first), the estimation part of the process was hurting the organization. I’m certain many of us can think of times when an estimate wasn’t used and really had no intention of being used.

Be sure though that it truly will not be used. This is important. If this is the case, then it has some degree of importance and then the level of accuracy and precision should be quickly assessed and the estimate done at that level. This brings us to a corollary:

Only estimate at the level of accuracy and precision required (or that has no incremental cost above what is required).

Often estimation takes time and effort. When estimation is needed to understand risk, then only do it at the level required OR if you can do it more accurately/precisely with no additional effort, then go ahead and do it the higher level. This also goes into thinking about creating sophisticated models or simulations that may be used. Bring these in when the situation warrants it, a good prioritized backlog of work, projects, etc. will reveal whether there may be a future for using one.

You may notice that both of these boil down to –

Simplicity — the art of maximizing the amount of work not done — is essential.

Hmmmm… I’ve seen that before.

One last principle:

Question whether this principle (or its corollary) continues to apply.

You may have determined you needed an estimate or perhaps you determined that it wasn’t needed; be sure this still remains true on a periodic basis.

I’ll close, ‘anecdotal’ circumstances are evidence. If you find that you don’t need to estimate under some circumstance, then that is a set of evidence showing a different reality. It’s very similar to observations made by Galileo and Copernicus that indicated that a geocentric view was incorrect and a heliocentric view was more accurate. Or perhaps an even better metaphor would be when Einstein was able to explain observations being made through relativity theory. It didn’t negate how classical mechanics worked under most circumstances, but there were circumstances (context) when mechanics needed to be replaced. If we never examined observations (anectdotes), then everything would remain status quo.

Facilitative Leadership Overview


In my last post I brought up the concept of a facilitative leader; so what do facilitative leaders do and how do the effectively lead?

What facilitative leaders do

I won’t go into exhaustive details here as this itself could be several posts, however it is important to have some idea what makes a facilitative leader distinct and that is the behaviors they exhibit. We’ll discuss this as if the behaviors are in the upper right of the Leadership Quadrant.

So in this space, a facilitative leader exhibits a desire to serve others, much like a servant leader as described by Robert Greenleaf. They also are participatory in nature, thus rather than say define a plan for a group to do work towards a goal, she or he will help the people create the plan so that is theirs. Thus a facilitative leader is one who helps the group collectively solicit and select creative ideas for the work and committing to complete it.

They also help individuals cope with their ever-changing roles and responsibilities as the team organizes and executes the work. They act as outside observers and offer improvements to the group and overall organization at large. They help the group gain clarity in the goal. They lead through influence.

How facilitative leaders effectively lead

As we explored in the last post, in order to be an effective leader, particularly when using influence as your primary mechanism, one must maintain good will with those you are leading.


When your actions are opposite of what you say you will do, they work against each other and your will approaches zero. Since influence is based on will, this reduces your leadership effectiveness.

Here’s a few examples, I say I have an open door policy and will listen and attend to people’s needs. If people bring these to me and I never listen, perhaps always finding ways to dismiss their needs, or I never take action when I say I will, I am undermining my will and thus my ability to influence behaviors, my primary mechanism to lead.

If on the other hand, I state I will observe where people appear to have roadblocks and help them through them, followed by attending stand-ups hearing of impediments outside a team’s control and visibly taking action on them, I gain will to get things done.

Side note: for most of this article, I called people a group, that was to emphasize two aspects – 1) this can be done in a non-team environment, particularly if you are a leader that has authority. And 2) you actually don’t need to have authority to influence folks through will; this generally not true where you are directive in nature, there you needed to have been granted authority in some manner.

Organizer’s Take Note: a Plea for Improving Unconferences

This is a follow-up post from my previous post “What is the Matter with Unconferences“; if you haven’t read it, please drop by and do so – we’ll wait…


Back? great!

As one other clarification, here is a Wikipedia extract that outlines what a BarCamp is, which is what most of these I have been to is based on…

They [BarCamps] are open, participatory workshop-events, the content of which is provided by participants.

After seeing issues at both UXCamp and ProductCamp, I’d like to offer some suggestions.  What saddens me in particular is that so many sessions at this past ProductCamp were presentations.  While I like that at least the type was known to me beforehand, even some pitched as workshops weren’t hands-on.  And the presentation ones seem to leave little time for true discussion.

To provide some details on the disturbing trends and to offer some unsolicitied advice on changes to make:

  • People getting scheduled before the conference. I think it is OK to find out people’s passion beforehand, but let’s not schedule sessions before the unconference; unconferences are more than just crowd-sourcing topics
  • Using voting as a method for choosing what topics are in or out. People will follow their passions; I’ve been at sessions where I was the ONLY one that showed up as the convener; that’s OK.  I either went to another session or captured my thoughts quietly; I’ve also had others come join me after about 10 minutes from the start as they tasted a few competing interests and found the conversation we created more interesting.
  • Don’t provide A/V equipment for sessions. No mikes, no video. To have participatory sessions, the sessions should self-constrain themselves to being small where microphones are unnecessary. Unlike big formal conferences, we’re not interested in trying to determine speaker or topic popularity, people self-determine that… Several workshop sessions at ProductCamp were set-up auditorium style and the participation was limited to getting small amounts of input from the audience. The default format should be open discussion; workshops should be essentially the second option.
  • Don’t have any session format connote different levels of expertise; no panels of experts or ask the expert. Unconferences are awesome because they promote peer-based discussions. That young guy out of college may have more innovation in them than the greybeard of 30 years in the industry. You are not going to unlock that by placing one over another via a self-proclaimed or given title. Let that expertise emerge from the group and people will learn what they want to use or not. If a panel of people want to convene one, that’s fine, but don’t let people call themselves experts; it’s still a conversation.
  • Consider what a Keynote does; it constrains thinking and lowers energy. If you are going to have a ‘keynote’, consider building the schedule (in Open Space, we would call it a marketplace) before the keynote.  This then captures the tone of attendees without influence.  If it isn’t aligned with the keynote, so be it; now you know what is on people’s minds.  As soon as the keynote happens, people begin constraining what must be important is centered around it AND having someone talk at me for 45 minutes to an hour lowers energy levels for proposing sessions. Also, let everyone have a chance to propose a topic before letting others offer a second one.

Select a style and focus on it beforehand: Camps tend to be more hands-on workshops.  Open Space and World Cafe formats more discussion-oriented.  Also, can I ask that space be considered a bit better?  While I thought the digs at both the Goethe Institute (UXCamp) and LivingSocial (last ProductCamp) were cool spaces, they were not conducive to moving around or running an effective unconference given the number of people; perhaps decrease the number of attendees.

I’m going to be watching what these two camps in particular do next year; I may set-up a competing model that truly emphasizes peer conversations if this is the trend for these two.

PS – This is NOT considered a knock on the organizers – who did a wonderful job at the format that they decided to do, but either they do not fully understand (or want to execute on) what an unconference (Camp) is, OR they are being seduced by ever greater number of attendees/sponsors they can get in exchange for sacrifices on the format.  I’d invite them to consider their own personal motivations and perhaps incorporate them explicitly into their message.

Improv Games for Innovation – #InfoCamp Session

This was originally posted 2 Oct 2011.

At InfoCampSC, I decided to host a session on using Improv Games for Innovation to share some of what I learned from Mike Sutton at Agile Coach Camp.  It was a hit!

We played 3 games; I used the machine as a warm-up.  With 12 people, we had a nice machine running.  This machine was dubbed “The Library Stamper”.

We then moved into a game where I had 4 folks describing what they disliked or problems using MS-Excel.  Teams of two folks would cherry pick these problems and run and create a potential solution for the problem and then create a further idea off that one and so on until they had 4 ideas.  Then they were to go cherry pick another problem.  We really got some creative answers.  By using improv, it focuses you on just creating ideas and not judging them.

We next used teams of two taking turns to create a story line.  They had 30 seconds with their first round and then 15 seconds the second round.  The story line was quite creative (I feel sorry for Google) and fun.

(The photo of this seems to have gotten lost; if I can find it, I’ll re-add it…)

I summarized how the concept of Yes And… is the way to create new ideas building on each other.

We closed with creating a picture of how folks thought the session went. Each person got to add one line.  Here is the result…


We concluded it was a dragon (perhaps with a Maori bent)…

What is a Matter w/Unconferences

I’m sitting at an unconference and really feel compelled to write a note about what is wrong about MOST unconferences I attend…. Here is a definition so we can focus attention on what’s wrong:

An unconference is a conference organized, structured and led by the people attending it. Instead of passive listening, all attendees and organizers are encouraged to become participants, with discussion leaders providing moderation and structure for attendees.

Definition from

The disappointing thing I am finding is almost all of these have too many presenters or panels discussing ‘at me’. There is no true peer-to-peer discussion and/or hands on learning. And more and more of these are having their sessions being planned in advance.

One session at the one where I am currently had the title stated such that an audience was supposed to make decisions on what would be discussed yet the speaker had slides! How in the heck could this person know what was going to be proposed? Rather it was a case of twisting the proposals into what they desired to present.

I want folks planning these to be more conscious of this; please do not call your conference an unconference if you are having people talk at me.

Of course not all unconferences are falling into this trap, but most of those that are not are seeming to be open space events; I love open space, but a good unconference doesn’t have to be this format.

If anyone has a way of finding out beforehand where unconferences actually are falling more into a typical conference format, let me know…

Agile Coach Camp: Exhergizing

So it’s now roughly 24 hours since the circle was closed and after a good night’s sleep, I am physically recharged.  I was mentally recharged during the hole time…

Our Canadian friend Bryan Beecham (@billygarnet) tweeted out how he was simultaneously inspired, refueled and energized and Mike Bowler (@mike_bowler) tweeted out that he was exhausted.  I feel this way after just about every Agile Coach Camp, so I’ve coined a Boosism (think strategery but only better): Exhergized – the state of being simultaneously exhausted and reenergized at the same time – usually the exhaustion is physical and the reenergized is cognitive in nature, but I suppose they could be reversed.

I’ll be posting more about the Camp in the upcoming days, but thought I would get that tidbit out there…