LeSS/DAD experience?

#1

I feel like i’ve asked this question 100x, but…does anyone have any experience with any of the scaling frameworks other than SAFe? I picked up a book on DAD and I’m taking a LeSS class next year (when it comes near my area), but I’m curious to hear other practitioner feedback. The longer I go on with SAFe the more curious I get with the other options…is the key to true agility de-scaling? Looking for a conversation…

#2

Hey JayH - it’s a great question.
I’ve worked with (or more specifically added where I can added DA ideas to large programmes of work and portfolios.
DA and LeSS, in my experience are totally different approaches. DA (it’s still trying to lose the Dad form but they really should have thought about the name a little more - if SAFe is good at anything it’s brilliant marketing) is a very practical way of delivering software based projects at scale. It calls out the practical need to confirm different stages of discovery and design before going into longer periods of iterative development.
The reason that it’s not that popular is three fold

  1. It’s seen as waterfall or RUP in disguise (cos, ugg, if its got a stages it must be waterfall and waterfall, ugg, is bad). I actually think it’s closer to RAD and is a great way of doing things.
  2. It’s not business transformational - many of the scaled agile approaches no longer talk about scaling complex software delivery but transforming organisations into an agile organisation.
  3. DA struggles to have a space - it talks a good people-agile game but then talks about roles and documentation. The message is not that clear on it’s purpose. On the plus side I like it and it is starting to leverage a lot from the DevOps world along with organisations that have failed or what something different than SAFe.

This leads to LeSS which I have to admit I’ve not worked with but have worked along side or seen from a near distance. LeSS, from it’s originators, is based on the premises that Scrum is the best way of working and unless the whole organisation is running Scrum agility within the organisation will fail. This may or may not be true but it’s very much all in and can be an agressive way of working.

As for the key to true agility - who knows. I would say stay light and keep your eyes on the landing area :slight_smile:

John

#3

This is exactly the type of feedback I was looking for… Thanks!

#4

I have used the two-phase planning pattern from LeSS with good results. This is nice when you have multiple teams against a single backlog of options for a product, where any of those teams could do the work, albeit with some qualifiers where that’s not true and you would make an informed decision accordingly.

Think of an auto shop with limited bays. The theme is auto repair and there is a bay for each team. Now, maybe we only want the Greased Lightning team doing transmission repair, but any of them could replace brakes. I don’t know that I did it quite the LeSS way as I have no formal training in LeSS, just did reading online. Here’s a snippet: https://less.works/less/framework/sprint-planning-one.html

I think the SAFe PI planning (to me the most valuable bit in SAFe) is meant to be like this, where going into the planning meeting it’s not certain whether something will be done and if so which team will do it. But SAFe doesn’t do this frequently enough for my tastes. LeSS does this routinely. That was appealing to me.

Even if I got this “wrong” in the eyes of the LeSS community, I was inspired by my interpretation of this technique and it was useful.

#5

Why are you trying to attach to a framework?
At the end of the day what matters is to deliver good software, effectively and with the right functionality for your customers.

If you look a bit into Lean, you’ll understand that shorter cycle time allows a more efficient delivery and more frequent feedback.

From thereon you just need to understand your system of work and figure step by step how you are going to deliver more often and adjust from the reality of the market.

In practice it means a good flow of strategy & ideas from Business/Management with the teams (and I mean WITH not TO because this should be done more from workshops than telling, this is 360 degrees). The PI in SAFe is a good frequency to do this for instance. But you should look at morphing the teams to eliminate dependencies rather than map them with yarn strings.

In practice you should also establish a proper Kaizen. The big issue we have is that Managers and Executive have no comprehension of the quality being delivered. Doing Kaizen forces visualisation, visualisation helps communication towards improvements. Communication supports Gemba. This establishes a continuous improvement process of the process of delivery and the end product.

Instead of shooting for a model of operation, start from where you are, aim to shorten your cycle, filter down the strategic intentions, filter up the impediments and improvements. Adjust your ceremonies, information, team organisation continuously.

The biggest impediment you’ll find is middle management stopping flow to maintain their headcount. This is a major systemic impediment that needs resolving with senior management.

#6

I worked with an org through the start of their LeSS adoption. Here were some of my initial impressions. I hear after 1.5 years they continue to expand the number of teams using LeSS, and are generally pleased with the adoption.

Caveat: I’m not personally attached to any one framework. I just like using crap that works. :wink:

#7

I view scaling frameworks like a celebrity recipe book… Some of the recipes you use per the instructions as they’re great, some you modify to suit your needs, and others you know are shit and ignore outright.

I should reach out to Guy Fieri and see if he’d like to be on the cover of my framework :joy:.

#8

I’ve dogged scaling frameworks plenty, as my social media footprints will attest. Breaking dependencies and reducing handoffs is ideal, no doubt. That said, I don’t mind borrowing ideas from scaling frameworks to evolve to such healthier structures over time. So long as the framework isn’t an end state, it in whole or in part can be useful to learn.

Going cold turkey from functional specialization to You Build It, You Run It has never seemed like the way to go to me. I would not put a business at such risk by rushing from low performance to high performance ways. People need time to learn and change.

I dog Scrum, too, for being batch work versus continuous delivery of value; despite recent guide updates, that’s the majority behavior I see. I see batch and “potentially shippable” as the stated goal but not actually shipped most often, with many sprints before an actual release. But coming off Waterfall, Scrum’s an ok way to learn agility. Not the only way, but still useful.

Kent Beck just did a videocast, like 1:22 long, where he said something like, I can’t make you run like Facebook, but I can help you to be you. That’s my take, too. Borrow ideas, but fit it to your situation, and grow into a lowercase “a” agile organization unlike any other.