Frameworks to Scale Agile – Some comments

September 18, 2013

First, here is a page that starts to explain SAFe. SAFe is one of the better known ‘scaling agile’ frameworks. http://scaledagileframework.com/

You should also look at Larman and Vodde’s book: Scaling Lean and Agile Development. (They have other books.) Also see their LeSS (Large-Scale Scrum) framework, here.

Next, Jeff Sutherland and Jim Coplien and others have worked hard on ScrumPLOP. This describes a pattern language, that is a set of patterns around Scrum. This deals with more than scaling, but includes many scaling patterns. See here. As one example, see the Chief Product Owner pattern.

See also Scrum@Scale, which in my opinion is dealing with several issues at the same time, not just what I call scaling.

Next, here is a blog post by Ken Schwaber. Many of you know that Mr. Schwaber is one of the co-creators of Scrum.
http://kenschwaber.wordpress.com/2013/08/06/unsafe-at-any-speed/#!

See also Nexus, which Schwaber defined.

Next, is a longer blog post by David Anderson. Many of you know Mr. Anderson is the main advocate behind the agile “Kanban” method. (I say it that way because I think of kanban first as the ‘signcard’ idea that Lean uses. Which is notably different.)
http://www.djaa.com/kanban-anti-safe-almost-decade-already#!

A few comments by me:

First, I think Dean Leffingwell is a good guy who is trying to help. Some want to paint him as the devil, which seems silly. But whether all our ideas that ‘wish’ to help are, in the end, truly helpful…. that is another question.

There are a lot of ideas or patterns in SAFe that I know and love. What troubles me more is the ‘weight’ of the whole framework, not individual things in it. The implication of the whole thing.

In general, I think Anderson and Schwaber don’t agree very much on ‘things.’ Hence, I am struck by how much they agree about SAFe. Their concerns to me are very similar.

I simplify their concern as: ‘SAFe has some good ideas within it — maybe even all the individual ideas are good — , but the strong bias will be to implement it as a single big turn-key heavy almost ‘waterfall’ solution. No matter what the stated ‘intention’. And no matter what the particular situation. This is likely, in several ways, to be unhelpful.’

I want to note that I understand Dean Leffingwell has said that he does not want SAFe implemented that way. To which Schwaber and Anderson might say: ‘Well, he may say that, but de facto something else happens. I’d rather discuss the reality than his words.’

My general biases are these:
* some scaling in some situations … might help.
* I have seen very little proof that scaling (which I have defined below) helps. When compared to alternatives.
* In general, some scaling is not really necessary or useful. The answer should often be: “One real Team, one really good Team, would be better for this.” How much is ‘some scaling’? It’s a big world: how much this applies to you is for you to decide.
* in general, all scaling is ‘ugly’ (my technical term for it, which I need to explain more). Mainly because communication across more than 7 people is really hard. No amount of lipstick on the pig will make it less ugly. Still, some things might make it ‘less ineffective’.
* in general, all scaling would benefit by a KISS approach — keep it absolutely even more simple than you can possibly imagine.
* all talk of scaling inevitably mis-directs attention away from the core engine of activity: the Team. This is not good; minimize it!!!
* inevitably, ‘smart people’ involved in ‘the scaling part’ want to assume more importance and more control than they should. Greater importance and control should be given to the individual Teams.
* in the end, there are trade-offs. OK, you must decide your trade-offs in your situation. BUT: KISS. KISS! KISS!!!

Some notes:
* I think the term scaling should be restricted to having multiple [Scrum] teams work together.

* I think ‘broader agile adoption’ should be used when you want to have more and more teams use Agile. Perhaps all teams. But this is often also called “scaling.”

* Agile Transformation should mainly mean having the whole organization become truly agile, in values, principles, and practices. Not just the ‘development’ department (or whatever your firm calls it). However, it is fair to say that just introducing Scrum to a few teams almost inevitably leads to a kind of ‘transformation’. It tends to affect, as we say, ‘everything.’

* I think the term Distributed Agile or Scrum should be restricted to these two situations: (a) one team has members in more than one location (ideally only two locations and only one time zone), or (b) two+ teams must work together, and each Team is in a different location. I would prefer that (a) was called ‘distributed team’.

* As it is now, all these terms are used quite loosely. So that real communication is low and misunderstanding is likely high.

* In general, many firms attempt (a) Scaling, (b) broader agile adoption, (c) Agile transformation, (d) distributed agile (both versions) — all at once. As soon as one recognizes this, is is obvious that KISS is not happening. And one hopes the benefits of KISS are apparent. (One hopes the benefits are apparent.) As if by magic, the word cluster-bomb comes to mind.

Updated: 6/27/2018.