Getting started

I have often been explaining how a LeSS adoption gets started on various occasions, so I decided to write it down as an article, not to avoid doing it any more - I will still do it as the interaction alongside it is irreplaceable - but to make it a reference.

LeSS guide: Getting started

LeSS provides a guide to help get started.

“0 educate everyone” is to set a foundation for people to work effectively with LeSS. In the case of using volunteering (recommended), people need to understand first about what they volunteer for.

“1/2 define product and done” is to define the scope of the adoption. We can use the Feature Team Adoption Map to explore and describe this scope.

“3/4(+5) create feature teams and have one PO provide work” is to organize the people and the work properly in order to optimize for global adaptiveness and value delivery. We create one backlog and have multiple feature teams work on one shared backlog.

For more details, please read from the book or from here.

My usual approach

My approach follows the spirit of the “getting started” guide, with some variations and added details.

Deciding

In this period, we support for the organization to make the decision of LeSS adoption.

Some people in the organization get interested in LeSS and may convince more decision-makers or influencers to learn about LeSS. The education may be via browsing LeSS websites, reading LeSS books, and/or attending LeSS trainings. Note the difference in purpose between this training and the late training for everyone - this one is for deciding and the late one is for practicing.

Then, we define the product, and roughly the done - the detailed DoD will be specified later in the kickoff. The two definitions - of product and done - decide which part of the organization will be in the scope of the adoption.

Preparing

In this period, we prepare for the LeSS adoption, in specific, the kickoff.

We educate everyone as prescribed in the “getting started” guide. This education aims for practicing rather than deciding. Besides, we focus on making preparations in three aspects.

In the product aspect, we need to find a PO or APO who creates the initial product backlog or area backlog. Its refinement is usually arranged to happen in the kickoff.

In the organizational aspect, we need to finalize the group of people who will join in the adoption. It is recommended to use volunteering as much as we can. Due to this, we usually educate a bigger group than the final group. Then, we agree on the reporting line - to whom do they report? What changes are necessary for their performance measures? Where do they co-locate? etc.

In the technical aspect, strictly speaking, we can make no preparation and instead let the necessary improvement happen in sprints. However, in order to increase the probability of delivering value in early sprints, which is critical for change, I suggest to at least create a CI pipeline with a small number of unit tests and acceptance tests, through which we build some initial capability for iterative and incremental development.

Based on the efforts needed in those preparations, we set up a date for the kickoff, which serves as a target for completing the preparations. This preparation period usually takes 1-2 months.

Kicking off

The kickoff usually takes 2-3 days, with the focus on getting ready for the first sprint. The below is a list of usual activities in the kickoff.

• Self-designing teams: we have finalized the group of people in a LeSS adoption, and it is the time to form feature teams out of them. Self-designing teams is a recommended way of doing it.
• Initial PBR: the PO/APO has created the initial backlog, and it is the time for teams to refine it together. Teams learn about the product vision and the value of items, as well as specify the details for the top items so that they are ready for sprints.
• DoD and working agreement: we have had a rough DoD when deciding the scope of the adoption, and it is the time to add specifics. As defined in LeSS rules, we will define both common DoD and expanded DoD. The teams may create their working agreement for both within teams and across teams.
• Broad learning: learn about the current product through using and testing available versions; learn about the current architecture with 4+1 views; learn about the current code by walking through it; etc.

Sprinting

Right after the kickoff, we will start the first sprint by doing sprint planning. We deliver value iteratively and incrementally with feedback on our product, and we continuously improve our process with both team and overall retrospectives.

End note:

While I was writing this down, Bas had a talk about LeSS adoption at the recent LeSS conference. His talk covered a longer period, but getting started is a big portion of it; thus, it is recommended to learn about his approach and focus too!