SAFe, LeSS, DAD, and ScrumPLOP

October 20, 2013

First, I want to say that I feel each ‘large scale agile’ situation is different.  The key problems are different.  Therefore, the solution(s) should be different.

And I like the idea of patterns. This is the pattern idea: “Here are some things (patterns) that others have found useful, and maybe I can steal from them, and maybe even these things (patterns) will be useful for me.”

One of the nice things about patterns is that they start modestly.  They do not boast “oh, I am sure you MUST have this tool.”  They simply suggest: “Oh, you might find this tool useful.”

Here are some places where you can steal.  Because I like patterns, perhaps I like ScrumPLOP best.

SAFe.  Scaled Agile Framework, associated with Dean Leffingwell. See here.  Notice the lengthy glossary.  And you will notice a whole bunch of Scrum words that have been redefined.  Or slightly redefined.  There is quite a lot there.

LeSS.  Large Scale Scrum.  See Scaling Lean and Agile Development by Craig Larman and Bas Vodde.  I really like that book.  Here is some info on the web.  You will notice both similarities and important differences with what “Scaled Agile Framework” is suggesting.

DAD. Disciplined Agile Delivery, associated with Scott Ambler.  In some sense Scott has been talking about these issues for years. Now he and others have this site. Again, some similarities and some important differences as compared to SAFe and LeSS. [Note: Recently renamed to “Disciplined Agile.”]

Jeff Sutherland.  He has recently done some excellent work in this area.  Go here and also search for scaling.  You will find videos and slide decks.  Great stuff.

ScrumPLOP. The Scrum Pattern Language group.  The two key people behind this (in my opinion) are Jeff Sutherland and Jim Coplien.  I have already said I like the patterns idea.  I have worked with Jeff Sutherland fairly extensively, and I have only the highest regard for him. This repository covers many things, and is not just addressing the issue of ‘scaling’, however one might define scaling.  It has a number of ‘scaling’ patterns.  Some of the scaling patterns include: Chief Product Owner, Product Owner Group, Scrum of Scrums, Impediment Removal Team, Organizational Sprint Pulse, etc.  You will notice that some of the groups mentioned above use these same patterns, although they may call them something different.

I hope these resources are useful to you.

Again, I wish to remind you and caution you: Do not forget the individual team(s). It is rather easy to start talking about scaling and lose focus.  Humans do that.

If you have great scaling and bad teams, you have almost nothing. If you have great teams, and fairly weak scaling, you still have something quite powerful.  Don’t lose focus on what is important.

 

« « Why I prefer ‘Release Plan Refactoring’ to ‘grooming’ || ALN RDU: Joe’s Agile Release Planning » »

Posted in: Better Agile, scaling
Tagged: Tags: , , , ,

8 thoughts on “SAFe, LeSS, DAD, and ScrumPLOP”

  3. James O. Coplien

    Over the past five years the ScrumPLoP people have worked on a pattern language for Scaling Scrum. Most patterns that people view as having to do with scaling, in fact don’t: Chief Product Owner is not a scaling pattern: in my CSPO courses I tell people that even in simple products I want 10 POs for every Developer. I also teach people that instead of growing a Scrum team five fold they should work on process improvement to get the order-of-magnitude kinds of improvements we’ve seen in high-Kaizen Scrum teams. Scaling is usually bloat.

    After all these years the ScrumPLoP community found two things. First, there really is no “pattern language for scaling” anything. The nature of scale-free, adaptive systems is that scaling is germane to a deeper level than is expressed in the forms of the Whole itself. (Christopher Alexander puts it in his “fundamental process.” There are no Alexandrian patterns for “scaling a city.” One shudders to think of it.)

    And, second, the nature of Scrum tends to bear this out. Scrum is in most ways fractal in structure: it is a scale-free system. Scaling its form makes no sense. When Jeff made this explicit about a year ago, it explained why we were struggling with the scaling language. And it’s the nail in the coffin that’s caused us to abandon that line of work. We still have some loose ends to tidy up, as Joe’s description above describes some vestigial structures in there.

    I think that people who are looking for scaling are missing something fundamental about this scale-freeness or perhaps about the autopoiesis fundamental to Scrum; I’m not sure. It would be good to understand that. I suspect that people are used to scaling problems in hierarchical systems and are looking to reproduce those solutions in a Scrum context. I think it’s the wrong thing to do.

    ↓
  4. Joe Little Post author

    Hi Cope,

    Very interesting comments.
    I like the ‘don’t do it’ option, as I discussed earlier. Maybe I should have expressed more in the way you did.

    I am confused, I think about definitions. So, let’s agree that with a Scrum Team of 7 that includes a PO, we do not have scaling. And they can product one product.

    Now, if we have 3 Scrum Teams (7 people each) work together to produce one product, with each Team having a PO and then ‘at the top’ a Chief Prod Owner (CPO) guiding the ‘master product backlog’ — to me that is scaling. And the 4 (CSP plus 3 POs) form a PO group. Again, scaling, with the 3 teams.

    So, is that not scaling to you? To me, yes.

    To me, well, I will not give another example now, but when I imagine fractals, again that is scaling. Although we can agree a different kind of scaling than other forms.

    So, what do you mean when you say ‘scale-free’ above?

    Thanks, Joe

    ↓
  5. James O. Coplien

    Scale-free means that the form of the system looks the same at all scales. Too many people give hard names to the organizational form at the level of a single team in a way that makes them believe that the form is different when you add more people. Adding people doesn’t change the form of Scrum.

    Some of the things you are talking about are interesting, and may even be good, but that doesn’t mean they’re Scrum. Scrum has no PO group. No master Product Backlog (in fact, mentioning this in my opinion shows a fundamental misunderstanding of Scrum). You have either a Chief PO who owns the product and a team of POs who support him or her (Sutherland’s terminology) or a single Product Owner and a group who supports him or her (Schwaber’s terminology), but not both, as you suggest above.

    If we could stick to discussing Scrum instead of extensions into older methodologies I think it could be a cleaner discussion. In that discussion, I would argue that we need to distinguish between the fractal notion of self-similarity and the notion of adding people. The latter I call scaling, and it maintains the same attractors as the former. Since Scrum is a framework, we focus on the attractors. If you focus on the structure rather than the form, I fear you turn Scrum into a methodology. Reading your last paragraph suggests to me that you might be headed in that direction, and that’s the root of my concern.

    ↓
    1. Joe Little Post author

      Hi Cope,

      I can accept your definition of ‘scale-free’. But I do not think it is the ‘common’ definition — fits with the common definition of ‘scaling’. But I understand and appreciate your reasons for wanting to use it.

      To most of the people I speak to, scaling just means ‘adding people.’ In their heads, scaling does not say how the people will be added…in a self-similar way or in some other way. It is just, somehow, more people are contributing to one product.

      Next: My opinion is that for most people, Scrum is just a framework for working with one Team of 7. (Plus or minus whatever.) They have not thought whether or not it is Scrum to do fractals or larger, self-similar, patterns of having people work together. In my opinion, they think of Scrum as only what is in the Scrum Guide. And then they think of ‘scrum’ in a very loose way, as all the scrum books and articles and blogs and discussion groups they have read. And how they actually did it.

      Put another way, they are not Scrum experts, and they have not read nearly as much about Scrum and the ideas behind Scrum as you (or even as I). So, I am using words (surely too quickly) the way these ‘regular people’ use the words.

      Now, I agree we should use words carefully, so I take your point on that. And will go back and do that more — for example define words some more. But if we are going to define a word in a way that is much different than ‘common usage’ — well, we have to be very careful.

      ***
      Methodology: I totally agree with you on this. But again, most of the practical people I talk to do not even care why this is an important issue. Well, more and more are convinced that the ‘heavy’ methodology of waterfall is useless. But a lighter ‘methodology’ often seems attractive. I think we both and many others need to make clear why they should care. I will re-read my stuff and be more careful NOT to seem to be suggesting a methodology.
      ***
      Question: Do you have a good article or blog post — maybe roughly in the area of scaling — that you would use to talk about why ‘methodology’ is not so good? I think this would help. Maybe I will find one soon. My point is: Where is there a succinct discussion of this issue to help convince others? (Umm. Ken Schwaber recently did a blog post that is in this range…, as I recall.)
      ***
      I do want to suggest that people can take ‘the basic Scrum framework’ (eg, in the Scrum Guide) and ‘add’ things to it. When I say it that way, most people seem to understand. And then I am suggesting that one can add patterns that work well with Scrum, or add patterns that do not work well with Scrum. And most people can get that. And while I am saying this a different way than you would (I think) — I think I am essentially saying the say thing as you. At least at the general level.

      Next: I seldom use the terms self-similarity or fractals in the blog, because I find most people never use those terms, so they don’t really understand them. But, I agree that in general those ideas or characteristics seem to make the ‘thing’ more likely to work with Scrum.
      ***

      Rather than only speak of Scrum, let’s talk more, in that typical American way, about what works better and what works less well, and why.
      Is that ok?

      More soon. Thanks, Joe

  6. Jonathan Harley

    Hear, hear on the overly academic is of terminology. Although I too value word and concept precision, there is so little of it in the general consuming public that it’s just confusing for most to stand on that particular soapbox.

    I’m a little disappointed to see that the conversation stopped there, but I’m curious about how, if not using something slightly more structured, like SAFe or DAD, how one manages large scale development departments in an agile way.

    That is, one pot of money, multiple masters of spending/investment, mulitple technical domains, strategic development + maintenance of legacy systems, and hundreds of developers.

    Somehow, maybe it’s just me, but I can’t see a fractal or self-similar form of Scrum that deals with that natively. Please enlighten me.

    Perhaps a blog post on that subject (aside from SAFe, LeSS, DAD, etc.)

    Thanks for a great series of entries too – Jonathan

    ↓
  7. Alex Ballarin

    Hi,

    good (and short!) article. A more detailed part comes in the comments section.

    IMHO, escalating describes better this subject because I look at it from the organizational level (aplying Scrum in a concurrent and coordinated manner to many teams). Again, to me, i’ts clear that we need a way to coordinate efforts without loosing the flexibility and other benefits we get from agility.

    DAD is different from SAFe and LeSS because several reasons:
    1. It is goal based and not prescriptive (what to do, but not how concretely to do it)
    2. So it proposes roles but not exactly how they coordinate “above” teams. SAFe and LeSS do.
    3. DAD proposes goals and practices that are “enterprise aware” (although perfectly usable for a single team)

    To sum up, DAD can complement almost perfectly LeSS and SaFE. Perhaps SAFe is more suitable to a big organization needing less effort to move form a traditional functional organization to an hybrid-agile one, while LeSS requires a significant upside-down reorganization which is more risky and requires a total commitment from leadership.

    Alex Ballarin. Agile Coach at itnove.com in Barcelona.

    ↓

Leave a Reply