Takeaways from a talk about LeSS, an evening with Bas Vodde

Last week, NLScrum, Agile Consortium and ING presented a Meetup in Amsterdam with Bas Vodde about LeSS : Scrum in multiple scrum teams.
Or, as Bas mentioned on later: In a productive environment they do “Multiple team Scrum” and not “Multiple Scrum teams”.

These are basically my notes, it might not be a very consistent story.

About Trust

Because of the setup of the presentation, that was about the WHY of LeSS instead of the HOW, I remembered a valuable lesson: If you want people to work together and enable them to do the best job possible, you have to trust them with their taken on responsibilities AND never take those back.
The latter is a ‘natural’ but counterproductive reaction I have too, once in a while. It’s something I learned as a teacher a few years ago: children should learn themselves, I couldn’t make them do it. I was just the one facilitating the context. If they didn’t learn, they’d fail their test.
Their responsibility and it took them a few low grades to learn it.

It’s the same in a team: their work is their responsibility. And failing is an acceptable (even desirable) part of the learning curve of a team.

So this evening the role of a scrummaster became very clear again, but a bit broader defined as I did before:

The role of a SM is to make sure the organisation supports & therefore enables the team to do work in their preferred way.

About simple systems

Bas also talked about building a working context that’s "bare minimal". A bloated system will have a lot of unused or counter productive features, that will slow things down. I strongly believe in a system that has just enough rules to enable the work, but doesn’t prescribes the details. LeSS follows this strategy and it’s widely recognized, eg in the great video below by “Morieux” ( TED talk )

Just Bare notes

“Multiple team Scrum” and not “Multiple scrum teams”
" LeSS === Scrum " with

1 PO on multiple feature teams
1 Product Backlog ( and multiple sprint backlogs) for multiple teams

Remember this:

Don’t do component teams : Feature teams only.
Feature teams don’t have to be equal! Of course some teams are more specialised then others. It won’t be a problem.
Feature teams are able to talk to clients and have full control of the realisation of the request.
For teams 2-8 : Bring everything from LeSS in at once
For larger amount of teams : go easy…
“ DEV-OPS = Scrum with extended DoD” ( As we do with the BaaS team!)
“ An issue? How would you do it in 1 team? Can you do the same with multiple teams?”
“ An issue? How would you do it in private?
Why would you deal with it in a different way at work?”
“ A PO is about directions, a team is about details”
“ A PO has 2 tasks : Prioritisation, ( easy to scale) and Clarification ( which doesn’t scale and should be relayed to the teams). So in LeSS: the PO is responsible for, but not (primarily) working on clarification.