Achieving system optimisation goals in LeSS

Large-Scale Scrum(LeSS) has incorporated deep Systems Thinking ideas in its recommendations. Whether it’s the way Sprint Review is done or the recommendations around team co-ordination, LeSS recommends system optimisation over local.

In this short post, I would like to share two system optimization goals in LeSS out of many.

1. Organizational design to deliver the highest business value
2. Agility

Organizational design…

Traditional organizations have many layers of management with multiple siloed groups turning their machinery as fast as possible. As we all know, this siloed way of working results in local optimization.

To avoid local optimisation in the context of org design, LeSS recommends:

• Building team-based organizations through dedicated, cross-functional, long-lived teams
• Feature teams over component teams

The organizational structure itself is recommended to be lean with no functional organisations like a QA department, a release management or a deployment group. Teams are encouraged to work directly with each other without any intermediaries.

Agility

Agility could be defined as the ability for the organisation to turn on a dime for a dime. It is also the ability to change the course or direction with low cost and friction. See Continuous Improvement Towards Perfection for more.

To keep the post crisp, I will focus on a single backlog vs separate team backlogs.

In LeSS teams pick items from the one prioritized backlog rather than having separate team backlogs. You might be wondering, how can separate backlogs hinder agility as teams will be more so-called efficient if they can work independently? The answer is, having a separate backlog not only makes each team to be deeply specialized in one area, but also results in losing the focus on the overall priority. At the end, single specialisation is a bigger problem than becoming multi-skilled as a team.

The actual trouble with multiple backlogs starts when the organisation wants to change the priorities. Due to the nature of single specialisation created due to separate backlogs, the teams won’t be able to turn around quickly and learn new skills thus hindering agility.

The solution is to encourage building T-shaped “teams” and avoid allocating the items upfront to specific teams. Teams should get involved in multi-team PBR reducing the implicit backlog dynamics thus increasing agility and avoiding local optimization.

Reflections from a team manager after visiting the “Large Scale Scrum Conference 2016”

So… LeSS… !?!!

Well, I had read about it over last year or so - on the web and in the book scaling lean & agile development. In my role as agile and lean team manager I wanted more of LeSS after these appetizers - so I signed up for the first LeSS conference.

What was I geared up for? Pretty much just a positive anticipation but from the webpage I had this in mind:

So what was my experience of the conference then? Well… very interesting.

On a concrete level -

I was at times a bit disappointed yet at other times really delighted with what was going on. Experience ranged from slightly chaotic and confusing to really really great.

Low: A team experiment that initially felt confusing and some not so interesting talks that brought little new that value to me.

High: Talks and discussions packed with deep insight. E.g. Craigs talk on the topic of owning vs renting. To me in some sense about the right to have a meaningful work – presented in a transparent and professional way. Or as in Bas’ talk when he lit a camp fire and took us from the concrete picture of scrum into something more deep and meaningful.

On a meta level –

On a meta level, even lesser experiences have grown upon me. Some experiences have changed into being valuable as I reflect upon the deeper meaning and learnings from them.

What you see and understand is not always the only thing you get – it might mean more as you reflect over time, fill in the blanks and associate it with other stuff that you’ve heard or thought…

So for instance: the above mentioned team experiment had on a concrete level its fair share of miss-communication, people ignoring the role of the facilitator, conflicts and poor team dynamics. On another level it had very interesting and valuable learnings on as I started to observe was really going on. Tuckmans stages of team dynamics for instance. The real experience of self-organizating teams as another example.

I feel it is completely impossible to describe everything that happened on this conference in a short post - but I do feel that I learned a lot, at the same time realize that my organization also could contribute to the agile communities outside my company… and most of all:

I really really appreciated the professional experimental culture with learnings that emerged even during the conference – and impacting the way it was conducted!

Some of the principles – build bottom up, fill in the blanks, experiment and inspect and adapt, self-organize was something that I did not only hear about – I actually was allowed to experience and be part of experiments with said principles.

Do I want more of LeSS after this conference?

O yes.

As a manager that really wants agile I feel liberated from some of the stuff I learned.

Thanks to all that made this a great event from Magnus – ever learning agilst and team manager

These are summaries and photos of some of the Open Space sessions that were held during the LeSS Conference in Amsterdam.

Open Space board

Fearless leadership

Leaders need courage to build an Agile Learning organization, unlike a coordination based Tayloristic organization.

Background material from www.coordinationchaos.com (under construction, updated by Sep 15th )

Courage is needed because:

• You need to trust the people, not control them
• You build a system with feedback mechanisms built in
  • From the work, for example Continuous Integration. This is expensive and requires skill.
  • From the customer, like in Lean Startup. Going out of the office is scary.
  • Self-reflection of the system, for example retrospectives. Reflecting own tribe is even more threatening than reflecting oneself.
• Benefits from learning come after a delay.

Main learnings:

• The worry of the middle management losing their jobs needs to be addressed more thoroughly
• Name fearless is not good…

Large Scale Retrospectives

Communities

Creating LeSS Questions

How to engage middle management

Getting executive buyin for LeSS

Non-software LeSS

This post is a place for putting the output of the Sprint Review Bazaar from the LeSS Conference. It just lists teams and their output.

Video of the Sprint Review Bazaar

Blessed Scrum Bags (winners!)

The Scrum Bag Island Game:

Red LeSS

The LeSS Keizers

The Doubles

The Flying Fish Team

BorderLeSS

RidicuLeSS

The Muppets

3M (Music Makes us Move)

Bartenders

Unfortunately failed to produce a shippable product…

After the LeSS Conference in Amsterdam, I was so lucky to join the after party in Craig Larman’s AirBnB place with most of the LeSS trainers. I showed them the “Emerson’s car racing game” and we played together. The LeSS trainers liked the game very much. I was not surprised that Craig eventually won the race game:-) Here’s the spec of the game in Gherkin language.

# race_game.feature
Feature: Emerson's car racing game
  In one of the Odd-e company gathering, our colleague Emerson Mills
  introduced a game he invented. It's a simple game that is fun to play
  with 3 to 10 people. The game helps people to understand *technical
  debt* and *legacy code* in software development.

  If we made this into an online game, probably we can have more people
  to play together. It might be fun to play in a conference with many
  people and don't forget to provide the final winner a bit of rewards.

  Roles in the game:
    Organizer: Start the game, call for next tick
    Players: In each tick make choice, play the dice and move his/her "car"

  In an offline game, the "car" can be a card, on which you can mark the
  current number of damages. But we sometimes use our phones, and everybody
  remember their number of damages.

  The final should be at least 10 steps from the beginning line.

  Scenario: start a game
    Given the organizer created a game
    When a player join the game
    Then the player's car should be at the beginning line with 0 damage
    When another player join the game
    Then there should be two cars at the beginning line

  Scenario Outline: play a tick
    Given a player's car has existing number of <damages>
    When the organizer starts a new tick
    Then he should be asked to choose if he want to go 'normal' or 'super'
    When he makes a <choice> and the dice show <number>
    Then his car should <go steps> with <expected damages> on it.

    Examples: Player chose 'normal' and played odd numbers
      | damages | choice  | number | go steps | expected damages |
      |      0  | normal  |    1   |     1    |           0      |
      |      0  | normal  |    3   |     1    |           0      |
      |      0  | normal  |    5   |     1    |           0      |
      |      1  | normal  |    1   |     0    |           1      |
      |      2  | normal  |    1   |     0    |           2      |

    Examples: Player chose 'normal' and played even numbers
      | damages | choice  | number | go steps | expected damages |
      |      0  | normal  |    2   |     2    |           0      |
      |      0  | normal  |    4   |     2    |           0      |
      |      0  | normal  |    6   |     2    |           0      |
      |      1  | normal  |    2   |     1    |           1      |

    Examples: Player chose 'super'
      | damages | option  | number | go steps | expected damages |
      |      0  | super   |    1   |     1    |           1      |
      |      0  | super   |    2   |     2    |           1      |
      |      0  | super   |    3   |     3    |           1      |
      |      1  | super   |    1   |     0    |           2      |
      |      1  | super   |    2   |     1    |           2      |

  Scenario: end a game
    Given player1's car is 3 steps from the final
    And   player2's car is 3 steps from the final
    And   the organizer starts a new tick
    When player1 goes 3 steps
    And  player2 goes 2 steps
    Then player1 win
    And  player2 doesn't win
    And  this is the end of the game

  Scenario: Organizer starts a choose-first tick
    Given I've joined the game
    When the organizer starts a new choose-first tick
    Then I should be asked to choose if I want go normal or super
    And I will see the dice play after that

  Scenario: Organizer starts a choose-later tick
    Given I've joined the game
    When the organizer starts a new choose-later tick
    Then I will see the dice play first
    Then I should be asked to choose if I want go normal or super