This page is shown in English as no translation to Русский is available.

Getting Started

The three adoption principles include that it’s best to start with one product adoption. How can you increase the likelihood of its success?

  1. educate everyone
  2. define ‘product’
  3. define ‘done’
  4. have appropriately-structured teams
  5. only the Product Owner gives work to the teams
  6. keep project managers away from the teams

0. Educate Everyone

The best LeSS adoptions we have seen had everyone participate in several days of Scrum and LeSS training. This was followed up with team, organizational and technical coaching.

Teach why—Besides educating on the what’s and how’s of adopting LeSS, it’s even more important to help everyone understand why. There is too much blind adherence to processes without understanding why.

A great trainer and a great coach will make a world of difference in your LeSS adoption. How to chose them? You can find some guidelines here.

1. Define ‘Product’

Your definition of Product will define the scope of your LeSS adoption. Prefer broader product definitions because they cause the following benefits:

  1. Better overview of the whole product
  2. Finer grained granularization
  3. Dealing with dependencies via feature teams
  4. Better focus on the problem users try to solve than on the solution they propose
  5. Allows for de-scaling the organization

2. Define ‘Done’

A better and stronger Definition of Done (DoD or ‘done’) requires a broader skill-set within the teams. For example, when performance testing is included in the DoD then the teams need to acquire these skills. This can be acquired by learning but often it is acquired by moving a person with performance-testing skill from his specialized performance testing group into the team. On the other hand, when performance testing is excluded from the DoD then the separate performance-testing group will stay and operate the same way as before, until the DoD is expanded.

A better and stronger Definition of Done results in more organizational change than a poorer and weaker one.

And a weaker DoD causes additional risk and delay!

The effect on the amount of organizational change makes the DoD a critical management tool for LeSS adoption.

3. Have Appropriately Structured Teams

Each Team has a shared responsibility for achieving their shared goal. To support their success, ensure each is an appropriately structured team.

This new structure implies people move from their functional groups to new cross-functional teams. Should people maintain a reporting relationship with their old functional manager? No. It causes conflicting loyalties that destroy the team’s shared responsibility and cohesion.

4. Only the Product Owner Gives Work to Teams

Focus is important. How do they lose it? Well-intended perfectly-reasonable interruptions and requests for extra work from their line manager, Sales, the CEO, HR, etc. Don’t let that happen!

Prevent this by ensuring that the Product Owner is the only person who can give work to the teams. Not only does this support focus, it reduces stress caused from trying to manage competing voices all saying, “Me first! Me first!” Prioritization is the Product Owner’s problem, not the team’s.

One voice to especially focus on banishing is to…

5. Keep Project Managers Away from the Teams

The role of project manager ceases to exist in experienced LeSS organizations. The role is not needed anymore as the project management responsibilities are shared between Product Owner and Teams.

Most LeSS adoptions can immediately eliminate the project manager role. In some adoptions the role is temporarily still needed. That’s usually when there’s a weak imperfect Definition of Done (hence, Undone work) or cross-product-boundary coordination. In those cases, organizations do not necessarily immediately forgo their project managers.

So sometimes project managers will still be around for awhile. What’s the problem? It’s likely they would regularly interrupt people and introducing conflicting priorities.

In essence, this recommendation is the same as “only Product Owner gives work” but more specific, and—we’ve discovered—important to make explicit.