Wednesday, September 18, 2013

Frameworks to Scale Agile – Some comments

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

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

Next, Jeff Sutherland and Jim Coplien and others have worked hard on ScrumPLOP.  This is the 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.

Next, here is a blog post by Ken Schwaber.  Many of you know that Mr. Schwaber is one of the co-creators of Scrum.!

Next, here is a longer blog post by David Anderson.  Many of you know that 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.)!

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 in SAFe that I know and love. What troubles me more is the ‘weight’ of the whole framework, not individual things in it.  The implications of the whole thing.

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

I simplify their shared concern as this: ‘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. And 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 is inevitable.
* 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’?
* 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 ‘more effective’.
* 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 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 that 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.

* I think 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 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’ only.

* As it is now, all these terms are used quite loosely.  So that real communication is low and mis-understanding 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, the benefits of KISS are apparent. (One hopes the benefits are apparent.)  As if by magic, the word cluster-bomb comes to mind.

No comments: