The Good, The Bad and The Ugly of Large Scale Scrum (LeSS)

lssHaving just attended Craig Larman’s 3 day LeSS (Large Scale Scrum) training course, I’m full of thoughts:

The Good

LeSS comes from a good place – a scaled version of scrum! There is a real effort not to add anything when scaling to multiple teams that is really not absolutely necessary and the spirit of scrum is preserved. Craig has poured a lot of relevant experience into LeSS. I sharpened up a few misaligned assumptions that I had with scrum – Eh, I didn’t know single team scrum as well as I thought. Then there are all sorts of practical implications of multi-team scaling which Craig has lots of really good thoughts on: continuous integration, communities of practices, the implication of self-organisation on hiring and firing practices etc. There was a lot for me to learn there and I think I need to reread the LeSS books again (oh, despite having read them, it seems like I could get more juice out by reading them again – see at the end of this post for links. Read these books!).

As with scrum. LeSS has an appealing purity – it describes the perfect end state (as opposed to the more messy approach of Scale Agile Framework) . LeSS is a marginally better than Scrum in describing how to facilitate some of the steps on the journey.

The Bad

LeSS proposes the immediate elimination of all overhead roles (project managers, testing groups, component development groups) as a first step and the forming of feature teams aligned to customer-value. Whilst a laudable idea and a direction to look in, in the organisations I have worked with, the complexity of the business domain and the state of the legacy code, means a wholesale adoption of approach would be bounced out immediately “You just don’t understand our business” they would say “Take your theories elsewhere.” Remember Conway’s Law? Systems resemble the organisations which built them. Slow, large complex organisations lead to slow, large complex software. “Our business is slow, large and complex – changing our product development organisation will just create a mismatch?”

When pressed for examples of where Craig’s approach had worked, Craig provided a lot of general references but was a bit short on details. I’d like to hear from large organisations who are not primarily software product focussed who have actually done this. It doesn’t seem to me that LeSS is well matched to the kinds of organisations I have worked with. It seems to be for small sub-set of software R&D focussed organisations who are so desperate they will try extreme measures.

And The Ugly

There will be massive resistance from middle management to introducing LeSS – since most of their roles are eliminated. Craig’s solution is to ensure support from senior management. I (and I project everybody in the room except Craig) have never come across this situation where senior management would be willing to provide this necessary support. They just don’t see it as enough of a problem to go through the pain. Craig walks away from organisations that don’t provide the senior support for the change – otherwise he he will just be “rearranging the deckchairs on the Titanic.” OK, fair enough. I project there are, maybe, only 1 in 1000 organisations who have the senior management support for LeSS. What about the other 99.9% of the market? How does LeSS help them take the next step on their agile journey (By the way, Continuous Improvement is one of the ten principles of LeSS)? It doesn’t. LeSS doesn’t even provide any help with this since Craig has no experience about making the problem visible to senior management to the extent that they are ready to take action.

In short, cherry pick ideas from LeSS. As a generalised scaling approach – a big thumbs down! The industry is still waiting for a good scaling approach!

larman2 larman1

Leave a Reply