Introduction to LeSS Conference

Large-Scale Scrum (LeSS), co-created by Craig Larman and Bas Vodde, is a framework for scaling lean and agile development to big product groups. The LeSS conference is a gathering of LeSS practitioners from different countries and companies, where they share their experiences on Scrum and LeSS adoption. For the fourth annual LeSS Conference hosted in Munich, there were two keynotes and three session tracks:

• Experience: Experience reports by people in LeSS adoptions
• Experiments: Practices to improve your LeSS adoption
• Open Space

For more details, take a look at the LeSS Conference webpage.

In the opening keynote, Bas expressed his intentions to make the LeSS Conference stand out from other conferences. Conferences in general are mostly about sessions and workshops, but the LeSS conference is more of a team-based conference. As such, your team is a very important factor in your conference experience.

Several round tables with materials were prepared in the hall where the keynote would take place. Because each team has to include members of different backgrounds, you would have to move between these tables promoting yourself to find your team. There were several criteria such as the number of times you attended the LeSS conference, your role (Biz, PO, scrum master, dev) in your team, your team size, the region you come from, and so on. My team had 6 members with various roles. Our team had members hailing from Taiwan (me), Germany, Russia, Singapore, and Brazil. When combined, we shared a proficiency in seven languages (English, Russian, France, Portuguese, German, Japanese, and Chinese), so we decided to name our team "Rosetta." Since forming up a team is an integral part of the LeSS conference, you don't need to worry if you plan to attend the next conference by yourself.

 

There were many team-focused events such as team reflections, team lunch, conference review bazaar, and so on. Team reflection time was especially important since several tracks progress simultaneously, teammates can split up to attend each track and then come back and share what they learned.

Open Space

During the afternoon of the first day, an Open Space was made available to all attendants. In an Open Space, people can decide what they want to talk about, when and where they want to do it. So not only are people participating in existing sessions, they can create their own sessions as well. People can either share their thoughts or engage in discussions. Open Spaces operate under four principles, one law, and two concepts:

The four principles:

• Whoever comes is the right people
• Whatever happens is the only thing that could have
• Whenever it starts is the right time
• When it’s over, it’s over

Law of Two feet:

• You use your own two feet to stay and learn, or walk and find another session. You are ultimately responsible for your decisions, and no authority figure will tell you to participate in one session or another.

Butterflies & Bumblebees:

• Bumblebees are people who tend to move from one group to another, picking up just a bit from each conversation. Bumblebees might then interject something in the next group providing cross-pollination.
• Butterflies are people who prefer to stand back and relax, waiting for someone to come to them for conversation.

 

With these ground rules established, people who would like to contribute presented their topics to all the participants, and then put their topics in one of the available time slots. It was impressive to see that a lot of people were willing to share their experiences or drive discussions. Other participants were free to join these topics at anytime.

  

Hosters grabbed a big post-it, and took notes during conversations.

  

Session Worth Sharing

Unlike most conferences, only some sessions were presentation-based, and most sessions were interactive group discussions. I'd like to share three sessions that were the most interesting.

The Five Relationships To Improve The Product Owner by Markus Tecza

In his session, Markus Tecza talked about the five relationships to improve the product owner. The five relationships are "product owner - team," "product owner - customers/users," "teams - customers/users," "product owner - higher management," and "product owner - scrum master." Four personas were introduced for each group to analyze the relationships in more detail. In the group exercise, we diagnosed the product owners, analyzed their five relationships with other stakeholders and marked them in different colors. A green line meant the relationship is very good, yellow meant improvement was needed, red meant very bad or not present. The next step was to draw the system model and make a suggestion for this product owner. "Peter" was the persona our group was assigned with. He is a product owner who controls a product owner organization, and makes production decisions directly. He loves to visit business partners, but does not involve himself in scrum meetings. He doesn't even know the names of development teams, and prevents teams from talking to stakeholders. In this case, we suggested increase "accuracy of backlog ordered according to highest customer value" and decrease "strength of control exercised." In order to increase "percentage of items product owner accepts on target system," we needed more "degree of CI practices performed," and more "percentage of predicted and done items," which will cause more "level of trust product owner has in this teams," and less "urge to control." Then it will increase "strength of control exercised" and "level of trust teams have in their product owner."

Chicken Breeding & the Core Design Principles by Craig Larman

In this presentation, we had a group discussion on what will happen when top performing chickens are picked up from each cage after 6 generations.

The answer is: 3 half-dead hyper-aggressive hens per cage, 6 killed from the remaining, and almost no eggs. Why? Because those high-performing chicken are bullies.

The next question is, what will happen if we picked up high performance groups after 6 generations?

The answer is: 9 healthy chickens per cage, and a 160% increase of total egg production.

This story tells us the importance of a cooperative society. "Best" individuals can cause a cooperative society to collapse. We started a discussion on what the common elements in LeSS are, and how 8 core design principles can be used in your group, and what the impact was on any of your common elements?

8 core design principles:

• Clear defined boundaries of the commons, clear group identity of those using it, & effective exclusion of un-entitled parties
• Proportional benefits & costs
• Collective-choice arrangements
• Monitoring agreed-upon behaviors
• Graduated sanctions
• Fast/simple & fair conflict-resolution mechanisms
• Local autonomy, authorized
• For groups that are part of larger groups, there must be appropriate coordination
• Among peer and tiered groups, with polycentric governance and subsidiarity

Number of Backlogs & Multilearning by Yi Lv

In this session, the speaker drove the group discussion to figure out the relation between the number of backlogs and end-to-end cycle time/adaptability. The step-by-step system model comes to the conclusion that more "backlogs" causes longer "end-to-end cycle time," lower "efficiency," and lower "adaptability." From this system model, you can also see more "number of backlogs" causes more "specialization," which causes less "knowledge breadth" and increase "level of collaboration." High level of collaboration causes high "integration time" and longer "end-to-end cycle time."

In another flow, less "number of backlogs" needs more "knowledge breadth," and more "knowledge breadth" increases "ability to adapt," decreases "switching cost to adapt," increases "adaptability." So multilearning is the key element to decrease the "end-to-end cycle time" and improve "adaptability." Fewer backlogs drives multilearning. Multilearning enables fewer backlogs.

(From Conference Slide: "Number of Backlogs and Multilearning" by Yi Lv)

Those are tips to help cross functional & cross component learning:

• Specification by example
• Collective code ownership
• Pair/mob programming
• Communities of practices
• Component mentor
• Current architecture workshop
• Multi-team design workshop

Conference Review Bazaar

At the end of LeSS Conference, team members took a few minutes to share their personal takeaways in a creative way by displaying them on big Post-its. The final session of the conference was "Conference Review Bazaar" (the marketplace). Which was set up like an actual LeSS review meeting. People could go around and check what other teams learned, then vote for the team that was the most impressive.

 

 

Conclusion

LeSS Conference was one of the most interactive and interesting conferences I had ever attended. Team-based conferences like this makes people get to know each other better and brainstorm many ideas. You can learn a lot about how other organizations are using scrum by interacting with participants from different backgrounds and regions. Not too many companies have adopted LeSS, with many Europe companies using SAFe. However, many participants came here to learn how LeSS works.

In LINE Taiwan, our engineer group is growing larger and larger. We are facing the same problems that LeSS tries to solve, like how to make communication between each scrum team transparent, how to decrease end-to-end cycle time, how to make teams more adaptable, and so on. Our direction is to make feature-oriented teams and increase multilearning. Keep specification by example (SBE), mob programming as our engineering practices. And utilize CI and automation more in our work going forward. We are making our scrum team members have a wider breadth of knowledge and become more agile.