Notes From Certified LESS Practitioner Course
I spent the better part of 3 days last week in a Certified LESS practitioner course with the awesome Bas Vodde, one of the creators of the LESS framework. I had so many ah-ha moments, and this is my attempt to document some of the key learning moments for me over the course of the 3-day course. These are my notes, and there is a lot more context that might help you as a reader. However, as you read, feel free to reach out if you want me to provide more context about any of the notes here, and that might feature as a blog post in itself.
Let’s get started!
If you must pick a practice to kick off your organisation’s LESS adoption, start with Multi-Team backlog refinement.
People-thinking VS Resource-thinking Mindset
People are NOT resources. A resource has a fixed use, and its utility doesn’t change over time. On the other hand, people do not have a fixed use; people are able to pick up more skills as time passes.
For LESS adoption to be successful, the organisation must adopt a people-thinking mindset, which suggests that people can learn new skills in a reasonable amount of time. Let go of resource thinking, which seeks to maximise the use of people’s existing skills.
In LESS, we want to intentionally create a mismatch between people’s existing skills and the skills required to get work done; this is how we will create a learning organisation.
Product Owner
The product owner cares about the product and not the team. In practice, the product owner orders the Product Backlog in order to maximise Value, and the team’s skill should NEVER influence the order; compelling the team to aspire to be cross-functional, picking up new skills as they pair with their team members.
Spill-Over
Spill-over can be defined as work that is started but not completed; a good indicator for teams that are not cross-functional and working as silos. Note that items selected for a sprint but not started within a sprint should not be regarded as spill-over.
Dependencies
There are two kinds of dependencies: asynchronous and synchronous dependencies. Asynchronous dependencies are experienced in component teams; teams can be restructured to remove these sorts of dependencies. On the other hand, synchronous dependencies manifest in feature teams and encourage collaboration between feature teams.
Learning Teams
In any LESS adoption, we want to create all sorts of learning opportunities within teams; learning about the technology and the product (domain), and as a result, we don’t want to create silos around areas of the product.
Travelling team members are one of the many ways to promote learning in a multi-team structure; this is a practice that could be adopted for a team member to learn or to teach but never done in a manner for a team member to follow the work, e.g., in a case where a team member has a preferred work.
Roadmaps
A roadmap is not a commitment; rather, it represents the lowest-valued objectives that might be delivered. If a roadmap was to change, that would be because high-valued objectives emerge and would replace objectives on the roadmap for the right reasons.
Management in LESS adoption
One of the LESS principles is that management is optional. Any management or coordination in any organisation is usually something that is taken away from the teams; hence the preference to return such back to the team in a LESS adoption.
Continuous improvement towards perfection
From a LESS perspective, the Definition of Done is a measure of the current team capability. Start by defining a Perfection Goal, and use the current reality as a starting point; the teams create a roadmap towards perfection.
Undone work
Work that the team never plans to do; in examples where regression testing is done outside of the team, but it is required before the product is shippable. Then regression testing will be Undone Work.
Feature Team
The internal language of a team is equal to the language of a customer.
Backlogs
Sprint planning is about design!
Do not use digital tools such as Jira for the sprint backlog. Sprint planning is internal to the team. Instead, use a physical board, and if you have a remote team, use tools that are designed for collaboration, e.g., Mural / Miro. Jira wasn’t designed for collaboration.
The use of a computer/projector centralises any meeting, and the person with the computer dictates the pace of the meeting. So as much as possible, have physical meetings and use a whiteboard to maximise participation.
About Kanban
LESS doesn’t like Kanban processes as Kanban suggests a sequential process, while LESS prefers working in parallel. In LESS adoption, team members are always pairing/mobbing on work.
Coordination between Multiple Teams
“Just Talk” - Decentralised, informal, and spontaneous communication every time.
It was an interesting course and it was nice to be able to sit and reflect with the other practitioners in the room. As you can see, I had quite a lot of key moments, but I love the fact that LESS is quite explicit about management support; without which the adoption will most likely fail.
Tags:
You Might Also Like
