The first two days of Certified LeSS Practitioner were engaging and challenging. I went
into the course thinking I could tweet interesting snippets as we went through;
however there was no time for tweeting or distractions it constant thinking,
doing, speaking. Hearing and following through the questions of others in the
course was often very interesting.
The last day was not nearly as engaging due to several
factors: I was tired, the content shifting to a light touch of the remaining
rules of LeSS and Venki mentioning we were on track to finish early; consequent
the participants but the brakes on.
Preparation
We were provided a long reading list of books, articles,
videos and set a knowledge test. The test was not referenced/used in the
training and some of the answer conflicted with Venki’s teaching. Several
people in the class had fragile knowledge of scrum, did none of the pre reading
and managed just fine. I had already consumed many items on the reading list
several years ago. I re-read some of the articles, watched a few videos and
found that they were not a cohesive set of learning materials. It seems they
were every public article of LeSS published, with lots of duplication included.
This reading list should be shortened significantly perhaps just to the rules
of LeSS and a video or two for background.
We were told to bring laptops to work on, but only needed one
per table of people to read the scrum guide. We were also encouraged not to
take electronic notes, instead were handed 48-page exercise books and
encouraged to take notes, which actually worked really well. My suggestion
would be that laptops were discouraged during the lead up and printed copies of
the Scrum Guide provided to each group.
Delivery
While the first two days were engaging, it felt like we were
on a roller coaster blind folded; only Venki knew where we were going. Jumping
from topic to topic without structure, without order, ignoring the printed
slides, it was hard to know if we were making progress. While it sounds
terrible I can’t make out if it is a strength or weakness of his delivery. As
questions were raised we would deep dive on the topic, the reason why and
potentially tangents to that topic.
Venki did make sure that everyone’s question were answered.
Sometimes those answers were in the form of a question, or reference to a
principle; forcing us to think through the question and find a suitable answer.
I feel that this approach was key to the engaging nature of the training.
Content
The content covered in depth was
- History of LeSS – If I have to hear “600 experiments” one more time…
- Ten LeSS principles
- LeSS is Scrum, what is Scrum, how are they the same, how are they different.
- Systems Thinking
- Causal Loop Diagrams
- The why behind the LeSS Framework
- The LeSS Framework (three pages of rules) and LeSS Huge Framework. Please note that this could be explained in two hours if done in one hit. Rightfully so it did not receive much more time than that through out the three days; after all we can always read the rules on the https://less.works
The content only lightly touched on was.
- The LeSS guides
I found it interesting that Venki played funny videos after
each break session. It surely lightened the mood, however only a few of them
were directly related to the training course. Most of them had a tenuous
connect at best.
Most of the interactive exercises were fun, interesting and
embedded knowledge in us; such as designing a multiple team sprint planning
approach, casual loop modelling of feature teams vs component teams. There were
several interactive exercises that fell down in delivery and/or opportunities
for learning. i.e. While searching for hidden post-its around the room with
types of wastes written on them was fun, yet it delivered almost nothing in the
way of knowledge.
What I took away
- Use LeSS to descale / simply the target area of the organisation through empirical process control.
- Don’ t use LeSS to scale up your existing agility.
- LeSS is designed for a big bang change (limited to the target area of the organisation). i.e. The vast majority of teams MUST be fully cross functional feature teams, otherwise you are not doing LeSS.
- The initial perfection vision of LeSS is a potentially shippable product increment every two weeks. Once that is achieved aim for one week.
- Concept of understanding the System Optimising Goal of all systems you are interacting in / part of. I.e. What is the company/CEO’s System Optimising Goal? Is that the same goal as your area? Is it the same goal as the tool you are using?
- Thinking in Systems: A Primer by Donella Meadows, is worth reading prior to the 5th Discipline by Peter Senge. “Thinking in Systems” will provide the though patterns that make it easier to digest “The 5th Discipline”.
- Using a WIP limit indicates that there is a problem that you are not solving. Perhaps another team is flooding your team with work? Perhaps your own has an uneven flow?
- Make all queues visible, then reduce/remove those queues.
- Use LeSS Huge only when your one PO can’t handle the number of teams that you have. The 2-8 teams for LeSS is just a guide based on the worst and best PO’s they have seen. 9 teams is not the trigger point for LeSS Huge, it is purely down to the ability of the PO to handle the teams you have or not.
- If you have LeSS huge try to only break out a new Product Area when you have 4 teams. This is so that the PO can keep those 4 teams effectively occupied. They have seen that having less then 4 teams for 1 PO often leads to starvation of those teams backlogs. So why do they suggest that use LeSS when you have 2 or 3 teams? The answer is that there is no better solution, better off using LeSS and potentially suffering some starvation than to not use LeSS when you have multiple teams.
- Product Areas may be made up of multiple “themes” this is especially true when those themes only need a team or two to service them. E.g. your 4 team Product Area may be made up of 2 teams for theme A, 1 team for theme B and 1 team for theme C.
- How can 1 PO handle 4 teams, let alone 8? The answer is to just to Strategy, Vision and Prioritisation. Leave the clarification of User Stories to the team who work directly with the customers. Cutting out this clarification effort frees up the PO to work with more teams.
- When you need to seed knowledge across multiple teams; try creating a temporary “undone” team with someone who is strong in the desired skillset and stack the rest of the team with people who are keen to learn that skill. Temporarily they do all of the work related to the skill, once they have learnt the skill, the team is disbanded and they take their new found knowledge back to their feature team.
- If you must have a distributed PO, place them in the same location as the customer(s) in preference to placing them in the same location of the team(s). The reason being they deliver the most value from better understanding the customers needs.
- While LeSS demands that most teams are Feature Teams, it accepts that there will be some service teams, such as finance, admin, etc. It also accepts that the feature teams DOD may not be complete especially in the early days. That undone work will be covered by team(s) called “undone”. The name was chosen deliberately to be unappealing, because the aim is to get rid of those team(s) ASAP and have that work done by the features teams within the sprint.
- Multi team Product Backlog refinement has recently been made the default over separate team Product Backlog refinement.
- Have a clear product definition is crucial to a successful LeSS implementation. This definition should be as broad and as end user centric as possible.
- The action plan from each team’s retrospective is shared at the overall retrospective. This is intended to prevent duplicated effort and worst still actions that interfere with each other.
- The Overall Retrospective is held early in the next sprint, it is not held on the same day as end of sprint.
- Every new role created in an organisation, disempowers another role somewhere in the organisation.
- Financial matters are handled by the Product Owner in LeSS Huge it is still the single PO that handles the $$$.
- Organisational agility is constrained by technical agility.
- To constrain your causal loop diagram choose 3 to 5 parameters of interest before starting the diagram and focus on them. This worked during the training; however I am concerned that choosing/guessing those parameters up front indicates that you already understand the situation which you often don’t when you are creating a causal loop diagram in the first place. I will need to test this outside of a training environment
Overall Rating: 8/10
