LeSS Q&A With Bas Vodde

Bas Vodde, co-creator of the Large Scale Scrum (LeSS) framework hosted an Open Space Q&A session at the 2015 Scrum Gathering in Prague.

I’ve posted an edited summary of the Q&A below as it covers a lot of common questions about the LeSS framework, and provides insight to why certain decisions were made.

Thanks to Bas for both hosting the session, and providing feedback and clarification on this summary.

If there is only one PO, who writes and elaborates Stories (Product Backlog Items) in LeSS ?

LeSS stays true to the original meaning of the Product Owner in Scrum.

The Scrum Guide does not say that the Product Owner writes stories, accepts features or does all of the clarification of Stories.

The Product Owner decides scope, priority and release of features, as well as provide the vision and direction for the Product. The Teams themselves clarify Stories. They work directly with whomever the requirement originates. This could be Users, Stakeholders, Customers or even the team themselves.

By design, LeSS does not have one PO per team. If many teams are working on a single Product it does not make sense to have the Product Owner responsibilities with each individual team.

LeSS replaces the Scrum concept of “Scrum Team” and “Development Team” with the single concept: “Team”. In a LeSS adoption, Business Analysts, Domain Experts and Proxy Product Owners become full team members. From there, they help clarify and understand requirements for the whole team.

Where does the Product Owner come from, and how do we ensure they stay close to the Customer?

LeSS implementations are usually in one of 3 different types of organization:

Product Development. These organizations usually have Product Management teams which make prioritization and content decisions. In this case, the Product Owner would come from that team, and supported by their colleagues.

Project Based. This is when a Client asks an Outsource Partner, or Systems Integrator to build something. In this case, it is best that the Product Owner comes from within the Client organization.

Internal Development. This is when a company is building an internal system. In these organizations Business and Technology are usually separate departments. In this case, the Product Owner would come from the sponsoring Business side.

Value should flow through an organization without going through hierarchy. The Product Owner should be peer to the Teams, focussing on the Product. Remaining close to the customers is a constant struggle.

In Project Based situations, it is often the case that the sponsor is not ready to supply a Product Owner. If this happens, one pattern is to create a “Temporary Fake Product Owner”. It is important to keep the “Temporary Fake” label as a reminder to remove the quick-fix.

How do you avoid Silo’s forming within Teams?

One of the principles in LeSS is “Whole Product Focus”. It is important to help Teams understand that the Whole Product is more important than each individual team. LeSS avoids silo-forming by ensuring that;

There is One Backlog (no individual Team Backlogs)

There is One Product Owner for the Product

There is One Sprint Planning Meeting

There is One Sprint Review

There is One Integrated Product.

Additionally, there is no pre-assigning of Product Backlog Items to teams. Teams choose items for refinement. If it’s not clear which team will be working on an item, then refinement is shared between more than one team.

If using Points and Velocity, it would be expected for teams to synchronize their system (this is possible as Points are a relative measure).

How do you Adopt LeSS, and make the change from Component to Feature Teams?

It only makes sense to adopt LeSS for existing products. New Products start with one-team Scrum and then expand (so LeSS is always a transition).

The guidance for adoption varies depending on whether it is LeSS (up to 8 teams) or LeSS Huge (more than 8 teams).

LeSS Huge is many LeSS implementations stacked on top of each other. A new role is added – the Area Product Owner, who takes care of a customer-centric area of the Product and view of the Product Backlog. Each Area Product Owner has 4-8 teams.

For LeSS, you MUST put in the full LeSS structure from Day 1. Give everybody a good introduction to what’s going to happen and why. Then make the change. Gradual adoption is more painful than biting the bullet and making the one-off structural change.

Self-Designing Team workshops are a good way to form Feature Teams. This usually takes a few iterations for the teams to assemble, and meet the appropriate constraints.

For LeSS Huge, the amount of disruption caused by an “all at once” adoption will destroy the organization. LeSS Huge should be adopted evolutionary and incrementally, and will take a long time.

There are 2 basic strategies for adopting LeSS Huge, one preferred and one which is common.

The preferred strategy is to build a parallel organization. This involves taking one Requirement Area, and implementing basic LeSS. This will create conflict between the old and new structures. This is because they are likely to be working on the same code, and may violate expected Code Ownership rules. Most of these issues are resolvable.

The more common strategy is to slowly expand the responsibilities of existing Component teams and move them towards Feature Teams. As the scope of the Team expands, the language begins to get closer and closer to customer terminology. A feature team is a team in which the language within the team becomes equal to the customer’s language. This would never be true of a component team, and is a good way to test if they are a Feature Team.

There is a 6 Step recipe for LeSS Adoption:

Educate Everyone

Define the Product

Define ‘Done’

Have Appropriately Structured Teams

Only the Product Owner gives work to the Teams

Keep Project Managers away from the Teams

Education is critical for LeSS success, especially as one of the adoption principles is Volunteering. If people don’t know what it means to volunteer, it dramatically reduces the amount of volunteering. The purpose of Education is not to get everyone into the “right” mindset by brainwashing.

LeSS abandons the whole idea of Projects, but this probably won’t happen from Day 1 as it may also mean changing governance structures. SAFe assumes Programmes and Projects – LeSS assumes that the focus is on the Product.

“What is your Product” is one of the most essential questions in a LeSS adoption. There are 2 rules for figuring out what is a Product:

Ask your customers (synchronize the external and internal views)

Is there one codebase?

Moving to LeSS means losing a lot of roles (for instance Team Leader). The question is whether they want to join a Team as a Developer, or take on another role such as Line Manager or Coach. The LeSS framework doesn’t provide guidance about having Line Managers within Teams. Be cautious with this as it can form an implicit hierarchy.

Some people see their value to the organization is within their Role, others see their value within their Skill. The people who value their Skills tend to become your best supporters. Whenever a Job Title influences someone’s behaviour, change it.

This is a systemic view in which culture is the result of structure, and that structure forms from culture. Practically, it is difficult to change culture (or mind-set): it is abstract and fluffy. Structure, however, is concrete – so easier to change.

In this sense it is impossible to do a pure, bottom-up LeSS adoption.

Having said that, there is no need for CEO or Board Level commitment, depending on the scope of the change. The most common change is the abandoning of Functional Departments and Component Teams.

What happens with Team Product Owners when transitioning to LeSS?

This is going to depend on the person.

Usually, Team Product Owners would become team members, and help the team clarify backlog items. If the loss of PO status is an issue, the question becomes how best to use their skills within the organization – and figure something else out. One of the LeSS adoption principles is “Use Volunteering” – there should be plenty of other things to volunteer for.

See also the Lean Thinking Principle Job Safety but not Role Safety.

How does LeSS work with Shared and Specialized People?

As a rule, part time members are not allowed in LeSS Teams. Specialists such as Architects join just one Team.

It’s likely going to be the case that not every team, or Product Backlog Item needs the Architect. Within this context, the question becomes: “how do we create learning to reduce the dependency on one specific person?”

The selection of Backlog Items by Teams takes into account the skills within the team.

Backlog Items requiring the Architect will be chosen by the team containing the Architect.

Backlog Items where it would be nice – but not essential – to have the Architect would be chosen by other Teams. They would then be encouraged to learn the necessary skills to complete the Item.

Sometimes an individual is so unique that they can’t go full-time in one team. In this case, they can become a “Traveller”. Travellers are free to join whichever Team has the most need of their skill, full time, for one Sprint – as long as the Team agree. Over time, Team members will learn the specialization and reduce the need for the Traveller.

How does the Definition of Done work in LeSS?

In LeSS, there is one shared Definition of Done for the Product across all teams. This definition is the baseline. Each team can improve on the definition, but it cannot be worse than the baseline.

If one or more teams expand the definition, then managers help the remaining teams meet the improved version, and raise the baseline for all.

LeSS does not recommend more than one Definition of Done (e.g. one for Sprint and one for Release).

How do you work with Remote and Distributed Teams?

Distribution of members within a team in LeSS is not allowed – each individual team must be co-located.

Distribution of teams across many sites is not recommended. Although you can pay for travel and use tools such as videoconferencing they won’t solve the pain. Remote development will always be worse.