Actually, maybe we should venture down Dunbar’s rabbit hole. I think there is something useful there.
In terms of developing empathy, rapport, trust, safety, ownership, let alone coordination costs… a tribe of ~150 seems like an upper limit, regardless of what tools or technology we try to throw into the cave…
Doing some Research today on DAD… they focus on what they call a Large Agile team Concept. This feel like Scaled Agile Framework’s Agile Release Train with some slight twist…
Here is the link to it… http://www.disciplinedagiledelivery.com/agility-at-scale/large-agile-teams/
I recently obtained the Scaled Professional Scrum certification from Scrum.org . This is based on the Nexus framework. A lot of it is based on many people are already doing when scaling scrum but adds another layer with an integration team (who doesn’t do the actual integration BTW).
If anyone has any questions i’d be happy to answer about that.
I’m interested to hear more about the logistics behind planning and executing work when you have teams practicing different methodologies within the same ART. I learned in SAFe training that it is possible, but from what I’ve seen in practice, folks tend to shy away from that. In my personal experience, I’ve seen people lean towards suggesting that the teams decide together which methodology to follow. While it’s good to empower the teams with that decision, I don’t think this is really setting them up to perform at their best, as much as they would by practicing the methodology that they’re the most familiar with and that they’ve worked to optimize.
Would be curious to hear about this as well. I have not been through a full blown SAFe implementation yet. I am a test away from my SPC. I would be curious to when anyone chimes in on your question how close they are following the SAFe framework or are they skipping any of the parts. From my research and understanding when you don’t include certain parts of the SAFe framework things really do fall apart seems a little less forgiving them SCRUM in a lot of ways. If that makes sense.
I could see team doing scrum and kanban in the art if you move to through put instead of a normalized story points. We have teams with disfuctional story point estimation at the current org. So their velocities are all over the place but if you look at the throughput they constantly do 15 to 20 stories. actual count vs mystical number
Throughout for the win in my book.
To be fair, it isn’t always a vs. model. Nexus for example is just Scrum at scale. It does a lot of the things we all do today when taking Scrum from one team to many and puts a framework around that. As many would say, it is just common sense. That said, why not a vs. model? You can use Nexus in a SAFe environment for example and many people are. At the base of SAFe is Scrum and how do you scale from a single Scrum team to many working on the same product, Nexus. I spent time with Dean at Agile 2016 talking about this exact model and he totally agreed as well, Nexus can be used within SAFe as the way you scale your product teams from 1 Scrum Team to many. Same within DAD and the conversations I have had with Scott. DAD is not prescriptive to the point of saying what you use and encompasses many frameworks to deliver software and Nexus can be and is used within DAD environments.
What I’m really interested in is the paths orgs need to take to get to some form of agility at scale. The models are just that: Models. In that they are always wrong, but might be useful in helping plot a path from “Giant org that can’t get anything done” to “Giant org made up of a bunch of smaller orgs who get things done, with some way of keeping things more or less aligned”.
Of course, something like SAFe (or any of the others) isn’t something you can just drop on top of an org. Especially one that hasn’t even got the basics mastered, or who might be missing the technical plumbing around CI/CD.
I would venture to say that the Spotify model, insofar as it is a model, is probably the one of the 4 mentioned that is the least likely to inflict harm on the org, as long as it is used as a model of a what an early success milestone might look like as part of an ongoing transformation. None of the models should be viewed as a successful ‘conclusion’ to a transformation.
@enaiburg Eric would you be interested in doing a podcast around this topic. I know I would be very interested in hearing more. this topic is at the for front of almost every client I walk into. Let me know if that is something of interest and we can start to put an agenda together and throw some dates out there. Great discussion so far.
@enaiburg and @Leanleff a podcast on this topic would be really awesome. Combining elements of different scaling frameworks is an awesome topic.
@enaiburg awesome I will start putting some dates and will message you with some outline of topics we can tweak it from there. Keeping this topic to a timebox should be interesting. We might need to do this as a series. 
Just wanted to let everyone know of the availability of Enterprise Scrum. Enterprise Scrum currently has about ~10% of the market. It is the oldest scaling method – started in 2003, and it is both a scaling and genericity framework. So you can do scaled-up software development, or Scrum for: company management, marketing, compliance, HR, finance, etc.
There is a book on Enterprise Scrum coming out early next year, and classes and certifications starting in January of 2017.
Here is an introduction to Enterprise Scrum:
In my experience, scaling frameworks tend to be popular because they appear to provide an answer to the “What-do-I-do-in-this-complex-mess-I-am-in?” question. The more rigid the framework (i.e. the more clear cut / “Do this and only this”) the more appealing it sounds as it feels comfortable to follow a recipe as opposed to have to come up with everything yourself. However, once an organisation gets over certain size, it invariably grows in complexity (often exponentially) and that complexity makes it inherently unsuitable to any rigid framework.
Local context is everything and while “Do this and you will be fine” sounds tempting (because it means people need to think a less), it usually leads to a many undesirable consequences at a local and org level. It often results in a superficial adoption of the “recipe” and its practices without any deeper understanding of the “Why” and without actually delivering the desired org/business outcomes and benefits that prompted the adoption of a given scaling in the first place.
Scaling framework are useful and provide a range of approaches for organisations and teams to consider when scaling their agile delivery. However, the best way to scale is to start with a deep understanding of how the org works today, be selective about which practices from which frameworks to adopt (and for what reason), be sensitive to specific contexts and business needs (of which there are many in a large org) and to always remain focused on the “Why are we doing this” question.
#RantIsOver
Just attended a presentation by Craig Larman, LeSS founder. Of course he is a purist and I’m less than a newbie. Wondering how many companies are inclined to completely change their structure and maintain it as executives come and go.
I consider all scaling frameworks as a useful set of patterns and only apply what makes sense for my current environment.
First rule of scaling is don’t scale bad agile. Most companies appear to get this wrong.
9 times out of 10 I suggest basic Scrum and XP practices at the team level and try to protect the teams from as much BS as possible.
Only take the patterns that from the scaling frameworks that will help your teams deliver value.
BTW, just like many ‘scrum’ teams don’t do scrum. Many “SAFe” orgs don’t do SAFe.
Our job is to help them all be as agile as possible, not to be as ‘SAFe’ as possible.
-don
Please take a look at my blog which proposes an approach to compare these 3 and recommends contexts in which each might be appropriate…
Thanks,
Ravi.
