This is a response to the discussion with Martin Burns on Joshua Arnold’s blog about WSJF and SAFE. Martin tweeted “real SAFe talk is Program & up. By defn only 1% of people impacted”
And there you have it. By definition, According to SAFE, only 1% of people are involved in Program and Portfolio level.
Tony Grout and I worked with a large number of people at Skype to create something that Dan North and I now call “Delivery Mapping” (Part of “Business Mapping”). It is a collaborative framework that allows large or small groups of product owners to collaborate on the creation of an organisational level backlog. Rather than tell people what to do it provides some minimal constraints in order to force collaboration and ensure that the right conversations are happening. The outcomes of “Delivery Mapping” are a strategic organisational level backlog based on the team level constraints, and a map showing which teams are constraints, or have no work on the strategic backlog (i.e. Team level utilisation).
To create the organisational backlog, every product owner was involved, along with all of product owner management team. The ideal sweet spot was that tech leads and test leads worked with the product owner in this process. This means that about 20% of the organisation collaborated to create the backlog. Even more are needed to address the team rebalancing effort. It meant that a significant portion of the organisation were involved in strategic decisions, all playing a small part and aware of the bigger picture. Compare that to SAFE where only 1% of the organisation are expected to make all the decisions.
I actually advocate SAFE. They have an interesting story at the program level with the Agile Release Train (ART). It exists on a continuum at the extreme end to LeSS with its self organised feature team creation. That said, the fact that SAFE thinks only 1% of people are needed for the Portfolio and Program indicates that its creators (SAI) do not appreciate that the constraint exists at the team level. They still think that the constraint is the budget (with associated plug compatible programming units). It also indicates that they think some elite group should be solely responsible for creating the portfolio. Our experience shows otherwise.
The IT Risk Manager 
May 14th, 2016 at 5:17 pm
You’re over-interpreting, Chris, extrapolating from a necessarily abbreviated tweet.
My point was: only 1% of those involved – even those who are engaged in systemic improvement – are going to have a context that strongly extends beyond the team of practitioners enough and is strongly interested enough to want to show up to community events or buy books.
We know (like all activists) that others are less responsive to activism. It’s only a small proportion of ANYONE who engages in method beyond “what’s needed to do my job”.
One thing SAFe does (or at least tries to do) well: not mess much with team delivery and not add too much to team cognitive load. (And of course, if it were not so, our Agile Unicorn friends would decry it for that very thing.) It’s most actively different – different enough to sell books or fill meetings – upstream from the largest number of people.
Combine those two factors and the market for any community that has needs significantly beyond “get Scrum/Kanban working well & show up to a couple of extra collaborative meetings a quarter(ish)”
I’d be interested to see how many folk in *any* approach which extends to Team of Teams lift their eyes much beyond their own context to a wider environment.
May 20th, 2016 at 8:54 pm
Rather than base your critiques on 140 character tweets, maybe try reading some of the articles on the SAFe website? The idea that populating, grooming, and prioritizing the Team, Program, Value Stream, and Portfolio backlogs is 1% of the organization is laughable. In fact, SAFe explicitly states that teams should be involved in estimating and elaborating Portfolio-level epics when it makes sense to do so. In fact, from a Product Management perspective, what you described at Skype sounds very SAFe-ish to me.
May 21st, 2016 at 5:39 am
Hi Andrew, What we did at Skype is nothing like Safe. Why do you assume I haven’t done any research on Safe? My background is in Agile which is why I’m less than impressed that the RUP community is abusing the Agile brand.
May 26th, 2016 at 10:56 pm
I’m glad you think you’ve researched SAFe, but when you make categorically false and ignorant statements like this…
“That said, the fact that SAFE thinks only 1% of people are needed for the Portfolio and Program indicates that its creators (SAI) do not appreciate that the constraint exists at the team level. They still think that the constraint is the budget (with associated plug compatible programming units). It also indicates that they think some elite group should be solely responsible for creating the portfolio.”
…you prove otherwise.
The reality is, much of what you’re doing at Skype is very consistent with what SAFe advocates. I’m assuming you’re not doing big room release planning (which is more or less the sina qua non of SAFe), but for the scope of what you discussed in this post (i.e. contrasting your Delivery Mapping process with SAFe), SAFe is far closer to your approach than you realize. Realistically, SAFe teams on the ART are very involved with the Portfolio Epic Kanban process (i.e. the Portfolio needs their help to define and elaborate Epics, do spikes and explore design options, reshape or break epics into features and stories to more clearly surface the more valuable work, estimate, etc.).
Scrum at Scale, LeSS, and SAFe have far in common than they have differences. RUP has nothing to do with it (and Agile is not a “brand”). If there’s an “Agile brand” out there that is more curiously “RUP-like” than the others, it’s Scott Ambler’s DAD approach, but frankly DAD is a framework for putting together Agile processes based on process goals more than it is an evolution of the RUP model. RUP of course was no panacea, but it was a respectable improvement over how teams were doing large-scale software development prior to RUP. And then came the Agile Manifesto, and software development processes took yet another step forward. Coincidentally, 2001 is also about the time Leffingwell left IBM and began tinkering as a consultant to Rally, figuring out how to scale agile requirements, and exploring the concept of “big room planning”. From those experiences, SAFe was born.
Bottom line, you’re throwing labels around to denigrate people unfairly and you really ought to be above that. That, and when criticizing something, you should try and actually understand it properly first.
Good luck with Skype, I’m really looking forward to it being a product I actually want to use again.