Sprint Review Bazaar in the LeSS Conference Amsterdam

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:

blessed scrum bags 1
blessed scrum bags 2
blessed scrum bags 3

Red LeSS

red less 1
red less 2

The LeSS Keizers

the less keizers 1
the less keizers 2

The Doubles

the doubles 1

The Flying Fish Team

the flying fish team 1

BorderLeSS

border less 1

RidicuLeSS

ridiculess 1
ridiculess 2
ridiculess 3

The Muppets

the muppets 1

3M (Music Makes us Move)

another unknown team 1
another unknown team 2

Bartenders

Unfortunately failed to produce a shippable product…

Emerson's Car Racing Game

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

 

More engagement with LeSS

A hot topic in HR and Management I’ve encountered a number of times is “employee engagement”. In fact, according to Delloite’s Global Human Capital Trends 2015 survey, the most important problem and trend in HR is “Culture and Engagement”. The problem of lack of engagement isn’t new. The surveys related to employee engagement exist since the late 1800s and were even used by Frederick Taylor to study people’s attitude. So called “soldiering” phenomenon Taylor observed in his studies is that monotonous work had negative effects on motivation and engagement.

Today, many employees still see work as something that has to be done without caring too much about it. When I mention “You should have fun at work and enjoy it at least as much as weekends and vacations” I’m usually replied with cynicism. According to a Gallup’s survey, only 13% of employees are “engaged”, while others spend their valuable energy and time on e.g. Facebook during the work. More seriously: 64% is not engaged and additional 24% is actively disengaged.

Leadership is often given as the answer with the believe that it has a positive effect on engagement. There is, in fact, no significant research that proves this. Cesario Ramos explains in his blogpost these misconceptions, backed by several scientific sources.

There is a tendency to overemphasize the importance of leadership and overlook more important systemic problems in environment people work.

What effect does LeSS have on employee engagement?

The meaning of “engage” isn’t clear and engaging itself shouldn’t be the goal. Instead to create exciting, fulfilling, meaningful, and fun environment. Organizational structure in LeSS supports creating such environment:

Customer Centric and Whole Product Focus principles create purpose

Refocusing employees engaged in product development toward whole product and actual customer instead of local part or a local activity helps in making work purposeful. It answers the question: “Do I contribute to a whole product and therefore customer value?”. This is particularly important in large product development, where it is common to feel lost or irrelevant.

Some people are satisfied with their work without having a whole-product focus. How? They optimize what is in their control and this often leads to local optimization.
For example, the system architect tries to manage all complexity but has this nagging feeling: Did my contribution really work out?
Even more present is constant tension with other people involved in same product development. It looks as if there are many separate goals, instead of delivery of a single product.

People want to see an own contribution to have a positive effect for someone else, the customer. One needs to see this effect as frequent and clear as possible in order to get out of bed for more than only a salary and possible bonus.

This sense of purpose can be achieved by having a clear product definition and product vision. All team members are involved in this. This is usually during a workshop such as Product Vision Board, Product Vision Box, User Story mapping.

From there, the constant reminding of the product vision happens during Product Backlog Refinement where team members engage directly with users, customer, and other stakeholders. No matter the size of the product. When we compare LeSS to Scrum, LeSS ensures strong collaboration between teams and customer / stakeholders by having one PO for a whole product. Not one PO for each team as then the PO often stands in between users and the teams.

Therefore, teams see the achieved value via the quick and direct feedback received from customer / stakeholders. No “translator” such as BA, Product Owner, (Project) Manager, Architect in between.

Developer’s job enriched

Great developers today do not stare at their screen and avoid people. Not much of these jobs are left, and it is unlikely to improve in the future.
Working alone implies a lack of sharing and lack of shared responsibility. The effect is that code and (automated) tests tend to become unreadable for others.
The job is exciting and powerful (“I’m important to others”) in the beginning until it goes into production and everyone wants something from this single developer. This creates stress and frustration since there is no one to help out.

The job of a developer isn’t just writing code. Not even just writing quality code. The job of a developer includes continuous integration and test automation. But that is not it. Even requirements are part of a modern developers job. A big chunk of the time developer collaborates with customer, stakeholders and other developers.

“We hate meetings. Period!”

Meetings are passionately hated. They are dreadful, long time-slots, stolen from a developer by someone “more important”. And they always come too late. The goal of most meetings is unclear and people boast while you wonder “why am I here?”.

Despite this passion, the problem is usually not meetings in general, but the lack of involvement and empowerment to influence and decide what happens in the meetings. LeSS supports effective collaboration and meetings help achieve this. The people who hate meetings do get together, share, discuss, and make decisions…together. In other words, they do meet but don’t call them meetings.

Most developers I meet do not like large product developments (except salary part :-)). Why? It isn’t because they are large. Not because their products are insignificant as they are often important products with nice challenges and impact. But it is because there are so many wasteful activities between own work and creating value that effect of own work is much less visible.

Luckily, in my experience, there is hope! In a LeSS organization, the job becomes more meaningful, powerful, and circle of influence is significantly larger. And meetings become fun! They become places where creativity happens, complex problems are solved and continuous learning nurtured.

In a product group adopting LeSS, a developer can influence not only what happens within the boundary of her own team, but also cross-team and whole product. This is what creates a fulfilling work environment.

Manager’s job enriched

Managers often ask the question, “If I’m not supposed to decide what people should be doing, how they execute their work, then there is not much left for me to do. In the best case, I don’t really know how to do my job without this.”

Why would managers think this?

Organizations have often pushed the manager into a position where the manager is the one who makes things happen by defining what needs to be done, how the work is done and supervision. There is also a tendency to look up to e.g. Steve Jobs or Elon Musk as role models. But they misinterpret their importance. Despite all leadership or what I call “humbleness” training, if you as a manager are the one accountable and responsible for everything that happens on your team you will be skeptical about self-management.

Most managers involved in LeSS adoption find the change positive. The reason for this is found in their actual job before the change. Ironically, in strongly hierarchical organizations middle managers tend to be very busy doing not so inspiring work. E.g. yearly performance reviews, budgets, objectives, KPIs, reporting, hiring and firing people, salaries, and bonuses. In fact, such managers tend to make long hours especially during the last months of the year, and beginning of the next one.

The more satisfying part of their job tends to be rather a minor part. The fun part of being a manager (besides a good salary and status :-)) is that manager supports, helps and teaches teams with their knowledge and experience. Managers should also create spacetime where people can learn, grow and excel.

LeSS principles, rules, guides, and practices help to simplify or completely remove many of the annoying practices. This creates more time for the manager to be meaningful to her teams. Instead of continuously and under pressure deciding what people should work on and how they should work, a manager is very visible and contributes by resolving impediments, pairing with team members, personal coaching, organizing events, open spaces, etc. A manager is also a matchmaker between people across departments and other groups of people. Therefore, in LeSS, the role of middle management is capability building.

Also, self-managing teams do not happen overnight. It takes time and effort to achieve this. Managers play a crucial role in the creation of this mindset by very actively delegating responsibilities to teams.
In some cases although not recommended, managers become ScrumMasters, and sometimes go back to development and become valuable team members while still retaining all benefits.
However it turns out for each of them, I never met a manager who was not pleased how the job changed after transformation, although the ride towards this point can be quite difficult.

Customer’s experience with IT people enriched

In large product development, customer satisfaction is often a sanity check. Customer dissatisfaction is a symptom of organizational dysfunction. Any improvement is not sustainable if it is not reflected in some way in customer satisfaction. In case there is a lack of it, a never-ending blame game between customer and IT guys is played. Unfortunately, this blame game becomes de facto standard after being played for years. It results usually in a complex contract game where situation stabilizes and the problem is covered up. The blame continues and nothing has really improved.

Although “Customer collaboration over contract negotiation” is embraced in Agile practices, it is often not reflected in the reality of large product development.

For a customer, one of the promises of Agile development is close collaboration with a team that is able to fulfill a need in an iterative and incremental manner. We are talking here obviously about a real customer need, and not so-called technical need.
But, although teams on are so-called Agile teams, you can’t really talk directly to any of them.

Why not? None of the teams is able to deliver your wish on their own, and their focus is one application. In other words, part of the puzzle. They are component teams. A common example is corporate banking products that usually translate into a chain of many separate applications that need to be changed. Each of them is managed by a separate “Agile team”. A complaint from an internal customer I’ve heard a number of times: “I don’t even know who do I need to talk to about this”.

From the customer point of view, it becomes frustrating and impossible to be bold, try something soon, experiment cheaply, collaborate directly with developers. At that point, the customer tends to be cynical about the whole Agile thing.

In LeSS, this complex corporate banking need is the product or part of a product. Teams are organized around such a product definition, and since they are feature teams, each has the capability of making changes across many applications. The customer interacts directly with a feature team that is able to fulfill a need completely.

Collaboration in this context could mean:

  • Discussions about idea and possibilities
  • Doing experiments for one sprint and getting direct feedback on daily basis if needed
  • Finding out how difficult would be to get product / feature delivered, and whether it could create value at the end.
  • Delivering product iteratively, within few weeks or faster after having it prioritized by Product Owner.

This reduction of organizational complexity translates into the removal of the wall with IT people where blame game is reduced and contract game not needed anymore.

Conclusion

Therefore, LeSS has positive influence on engagement by:

Improving sense of purpose in large product development through principles of customer centricity and whole product focus
Broadening developer’s circle of influence through decentralized decision-making and closeness to the customer.
Enabling to take more meaningful work for people with role “manager”
Seeing more satisfied customer.

Decouple Line Organization from Requirement Area

This post is cross-posted from the Odd-e page at their blog

Decouple Line Organization from Requirement Area

After almost 10 years, I got chance again to work on a LeSS Huge adoption. Facing different challenges and reflecting on my experience 10 years ago, I am proposing an experiment here to decouple line organization from requirement area.

NSN experience

In 2007, I experienced an organizational transformation in NSN (Nokia Siemens Networks) to adopt LeSS, at which time the name “LeSS” had not yet existed. We had transformed the organization into a LeSS Huge setting with a few requirement areas, in each area there was APO (Area Product Owner) and Area manager. Area manager was the line manager for the area. We used the same name for requirement area and line organization, for example, the area I worked for was Traffic & Transport, both as requirement area and line organization. So, requirement area and line organization are coupled.

Even though the workload in one requirement area is more stable than one feature, if we follow priority based on customer value, it is inevitable that the workload varies as time goes. So, today you need 5 teams working on this requirement area, tomorrow you need 6 teams. I am exaggerating, this would not be “today/this sprint” vs. “tomorrow/next sprint”, but more like “this quarter/this year” vs. “next quarter/next year”. Anyway, this happens. When it happens, LeSS recommends to move team, rather than individuals, to other requirement area. When requirement area and line organization are coupled, it means that the team would also change the line organization. As you can image, line change is never easy. Everybody may agree that this makes sense and support, the necessary justification and convincing others carries big overhead. Even today when I reflected back, I could still feel the very pain. Yes, the silo among requirement areas was clearly there and the coupling with line organization made it worse. Interestingly, the developed silo was also one of the reasons why we chose to couple line organization with requirement area, because that way, line organization would have more product ownership, not for the whole product, but for the requirement area.

Although it was painful experience to move teams to different requirement area, it did not happen often, as the workload seemed stable in requirement area. In retrospect, i suspect that the prioritization decision may consciously or unconsciously take the capacity of requirement areas into account.

New challenge

Recently, I encounter a different challenge. In the context of my LeSS coaching client, their workload between two requirement areas varies release by release. Say, there are 5 teams in each requirement area. In release 1, based on priority, 60% of work is from requirement area A, and 40% of work is from requirement area B. That translates into 6 teams for requirement area A and 4 teams for requirement area B. However in release 2, only 40% of work is from requirement area A, while 60% of work is from requirement area B. If we have requirement area and line organization coupled, we basically have two options. First, we do not follow the priority strictly and take the work considering the capacity in each requirement area. Second, we move teams to different requirement areas release by release, as line organization is coupled, we change their line organization as well. As their release cycle is 3-4 months, it would be hectic to make so frequent line change.

New experiment

In fact, we have the third opinion, which is to decouple line organization from requirement area. Once it is decoupled, we may move teams across requirement areas but not change their line organization. Let’s illustrate this with the below diagram (RA = Requirement Area).

Decoupling line from requirement areas
  • 2 line organizations (A and B), each having 5 teams
  • 2 requirement areas (RA1 and RA2), with varying number of teams

  • Release 1, 4 teams for RA1 and 6 teams for RA2
  • Release 2, 6 teams for RA1 and 4 teams for RA2

The name for requirement areas is often associated with product domains (customer domains, rather than architecture domains). Hotel, Flight, etc. would be suitable names for requirement areas in Ctrip type of product, assuming that each is big enough to justify as its own area. However, we name line organization without referring to product domains. It could simply be product line group A, B and etc.

In LeSS Huge, one rule says that each team specializes in one RA. In this case, we can’t let A5 and B5 specialize in RA1 and RA2, respectively. Instead, we would like them to be able to work for both RA1 and RA2. Would that cause problem? Let’s first understand the rationale behind the rule. It is usually difficult for any team not to specialize in any area, as the whole product in LeSS Huge is too complex for any team. This holds true by and large. However, there are a couple of subtle differences here.

  1. We are talking about minority of teams, for most teams (A1-4 and B1-4), they still specialize in one requirement area. It is likely to enable small number of teams who can specialize in more than one requirement area.
  2. Team A5 and B5 may not specialize in RA1 and RA2 completely, but to some extent, e.g. some sub-areas in both RA1 and RA2. The key is to have the flexibility in addressing the workload variation in requirement areas across different releases.

Another potential downside for the decoupling is that line organization would not develop strong product ownership. While this is true for requirement area, too strong ownership for one requirement area may lead to silos within one product. Thus, the decoupling also has the potential in reducing silos if we can make any line organization care more about the whole product.

Conclusion

Regardless of what choice you make - either coupling or decoupling, I suggest you to understand deeply those forces in the dynamic, thus, make informed choice.

Terry's Agility Index

Recently, I was chatting with my friend (and a LeSS site developer) Terry Yin and we were reflecting on two different product development efforts.

He had been working with a client and the Sprint Review was boring as hell. People didn’t really care. Also the teams didn’t care whether they had done items during the Sprint anyways. When debugging this a bit more, it seems to relate to fixed-scope assumptions. Even though they said they had adopted LeSS, they still had this mindset of a fixed scope for a release. So, the Sprint Review led to no learning and no action, and the Sprints felt artificial.

On another effort where we were working together (smaller), we noticed that it was common to have the Sprint have all new items that weren’t in the Product Backlog in the previous Sprint. Most of the items were discovered during the Sprint Review. The backlog and scope was changing constantly. We kept a Release Burndown chart and it was going up, down, up, down, up and then when we decided to release, down in a straight vertical line.

The difference… true agile exploration vs agile movements in a traditional setting.

So, half jokingly, we came up with “Terry’s Agilility Index” which we defined as:

The percentage of new items during the Sprint that came out of the Sprint Review.

Since then, I’ve mentioned it a couple of times and it often surprised people. Lots of so called “agile” projects would have a Terry’s Agility Index of 0%. Now, 100% is probably not good either, but it is an interesting quick way of checking how fixed the fixed-scope mindset is in a product group.