Review of “Certified LeSS Practitioner” three day course by Venkatesh (Venki) Krishnamurthy

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

Breaking down the Coder vs. QA divide

The Coders vs. QA divide is prevalent in almost all companies that are new to an agile way of working. The Coders camp out on one side of the wall, throwing work over to the testers. Creating cross functional teams does not automatically resolve the ingrained ‘over the wall’ mental model of development. Often two mini teams form within the agile team, with the wall still very much intact. This mental wall perpetuates ‘Us vs. Them’ adversarial behaviour; which generally leads to late delivery, reduced quality, stressed testers, limited collaboration and frustration on both sides. Thankfully this issue can be addressed in a reasonable time-frame when the appropriate actions are applied as a cohesive approach.

The long term goal regarding Coders vs. QA is usually to blur the line between Coders and QA to the point that they are all ‘Developers’. Some of the Developers have more of a QA focus; however all of the Developers are actively involved in testing and quality throughout the life-cycle of the product. These Developers create and maintain a test suite that adheres to the agile QA pyramid. This is a long and rewarding journey to take; with breaking down the Coder vs. QA wall as the first major step.

How to identify that the Coder vs. QA wall exists

When you notice two or more of the following situations, it is likely that there is a divide between the coders and the QA.

• QA/Testers are the only people who test the software. No one else helps even when it appears likely the team will not complete a user story within the iteration.
• Reviews and showcases where teams discuss user stories that have been built, yet the user story has not been tested.
• Reviews and showcases where teams show user stories that have not been tested.
• Inconsistent velocity from teams.
• The testers are stressed at the end of iterations while the coders are idle looking for work, or worse still working on user stories from future sprints.
• All of the testing occurs in the last 10% of the sprint.
• Request to extend sprint duration because it takes too long to test the delivered features.
• Use of phrases such as “It is done, I have coded it, it just needs to be tested.”

How to remove the Coder vs. QA wall

My favored approach to removing the wall involves some carefully executed company level actions, supported by team level coaching. While it can be addressed just via team coaching; that does not scale well, produces inconsistent results and takes a lot longer. I recommend considering the following actions, remembering that these actions need to work together to change the hearts of minds of many different people.

Company-wide minimum DOD includes “User Stories must be Tested”. All teams must have a DOD that includes the ‘minimum DOD’; they are free to build upon if they wish.

Company-wide training which emphasizes

• Teams succeed or fail as a whole
• The whole team is responsible for quality, not just the testers.
• QA provide Test Thinking, however everyone in the team contributes to testing.
• Value of completed stories over partially complete stories
• WIP is waste
• WIP reduces our ability to change direction
• ATDD/BDD

Company-wide support for ATDD/BDD with

• Tooling and environments
• Expertise and coaching for the implementation
• Specific training for QA to develop their automation skills

Coach Product Owners to

• Value only completed stories.
• Demand to see only completed stories in reviews/showcases
• Demand to only see working software in reviews/showcases

Support team coaches/scrum masters to:

• Re-enforce the messages from the Companywide training
• Establish Coder/QA pairing
• Establish ATDD / BDD
• Work with QA to create a prioritise automation testing backlog. This backlog can be worked on by Coders/QA during slack time. Over time it will reduce the demand for manual testing, freeing up the QA to focus on automation, exploratory testing and building quality in.
• Run team exercises where team members learn more of the details of what each other does and how they can help each other.
• Provide training to the coders on basic of effective manual testing; so that they are better able to step in when needed.

Questions for you

• What has your experience been with Coder vs. QA divides?
• Have I missed any signs of the divide?
• Have you taken different actions that worked well or taught you what not to do?

Image by Helen Wilkinson [CC BY-SA 2.0], via Wikimedia Commons

Tree Root Diagrams, a powerful problem solving addition to the Five Whys

Solving problems in this complex world can be a huge challenge. The Five Whys is a powerful technique in our hunt for the root cause of an issue; however it rarely provides the full answer. Combining Tree Root Diagrams with the Five Whys can ensure that your team gains a full understanding of the root cause(s) of the issue. Once you know the root cause(s) a permanent solution is only a few simple actions away.

A Tree Root Diagram captures all of the causes linked to an issue in a downward expanding tree of causes. These diagrams often look like the root structure of a large tree. They are most useful when a group of people is collaboratively solving a complex problem.

The approach is straight forward: on a large whiteboard write your issue (really the symptom) in the top middle part of the whiteboard. Ask “What caused this to occur?” Write a very brief summary of each cause that is mentioned and draw an arrow from the symptom to each cause. Now repeat for each cause, building up your tree as your examine each cause. For each Root Cause you identify, circle it and come up with an action or two to address it. List the actions near the Root Cause and draw a line from the actions to the Root Cause.

Benefits of Tree Root Diagrams

• Finds multiple causes of a single symptom; including related issues.
• Visualizes the relationship between the symptom and its many causes.
• Visually links actions to the Root Cause the group is addressing.
• Allows the group to discuss tangential topics then return to the core issue without losing track of what they were up to.
• Acts as a record of what the group discussed and agreed upon.

More Examples

A simpler example

An example of when it is quiet linear.

A complex example

How I stumbled onto Tree Root Diagrams

Around July 2015 I was coaching some new Scrum Masters in effective problem solving and usage of the Five Whys. I keep hearing myself suggest to them to write down each answer to Why that the team called out. My intention being to get them and the team realized that the first answer is rarely the root cause. I quickly realized I was not doing this myself and set out to walk my own talk. What I found when I made a concerted effort to write down the causes, was that there were often multiple possible answers to each Why. Hence my notes quickly turned into tree diagrams which I labelled as Tree Root Diagrams and have used ever since.

Ishikawa diagrams

Tree root diagrams are similar yet different to Ishikawa diagrams turned 90 degrees. Ishikawa diagrams focus on categorizing the different causes in a hierarchy. Tree Root Diagrams focus on the linkage between causes; of potentially very different categories.

Choosing the correct type of feedback can improve your coaching

Helping people to grow and improve is very satisfying. Hence constructive and re-enforcing feedback seems natural to me and I use it often. However there is a continuum of behaviour that prompts me to give feedback and unfortunately it should not always result in re-enforcing feedback. The feedback approach coaches’ use should change to suit the type of behavior we are providing feedback about. Choosing the correct approach is crucial in effecting the outcome that will help the individual, team and yourself.

Adjusting feedback

Use Adjusting or Corrective feedback when someone is doing something that they must stop, or must change. I.e. Their behaviour is destructive, career limiting, negatively affecting others.

• Do prepare (gather specific examples of the behaviour, talk to peers, draft what you will say, practice what you will say)
• Do follow a structure and be directive in your delivery. Here is a template that you can use: it has been observed here, here and here, that you are doing X which is causing Y, this behaviour needs to stop, because it is causing Z. If the situation comes up again please do A instead.
• Do give this feedback is private.
• Do not give this feedback immediately after the event. Make sure you wait until everything has calmed down, so that it can be talked about in a rationale and deliberate manner.
• Do not combine with other types of feedback, as it sends mixed messages.

Constructive feedback

Constructive or developmental feedback should be used when helping some to do better, or to help them see opportunities that they missed. 

This is covered in combination with Re-enforcing in my article Coaching Scrum Masters. The feedback sandwich puts two slices of re-enforcing feedback around a sliver of Constructive feedback. I have found this approach to be highly effective and have received plenty of positive feedback about it.

Re-enforcing / Encouraging feedback

Use it to praise people for effective behaviour and encourage them to do more of it, and perhaps do it even better next time.

• Can be given in public (as it publicly promoting the behaviour that is appropriate), however be aware of who you are giving it to, some people will be embarrassed through to down-right upset at public acknowledgement. 
• This type of feedback should be approached as discussion with the recipient. You are not telling them to repeat their behaviour you are merely discussing the benefits that you noticed and that you would like to see more of that behaviour.

What is it, to be an Agile Coach?

I am ...

a teacher - providing people with new knowledge.

a trainer - running people through exercises and giving them feedback, so they can improve their skills.

a networker - connecting people so that they can help each other.

a mentor - encouraging people to grow and improve.

a facilitator - organising events/ceremonies/meetings ensuring they deliver results while involving everyone.

a coach - helping people to grow, through thinking differently/ thinking about new things.

an agent of change - working tirelessly to improve how people, teams and companies operate.

a councilor - really listening to people as they talk through their concerns.

a supporter - helping people through tough times.

a student - always learning from others, reading, listening, observing.

a scientist - running experiments and sharing what I learn.

a statistician - gathering data, analysing that data, and sharing my thoughts. 

a historian - recording and explaining the history of projects and teams, both successful and unsuccessful.

an author - writing my blog for others to read.

an orator - speaking in a language that my audience can clearly understand. 

an evangelist - shouting out loud and proud about what I believe in.

a leader - providing direction to those who call for it.

a team member - mostly working with others to achieve my goals.

an agile coaching - helping people, teams and companies, to make their work life more fulfilling, enjoyable, effective and efficient.

Are you like me? What can we learn from each other?

Photo Credit: Phil W Shirley

Coaching Scrum Masters

In my coaching work, I find that any effort I put into coaching Scrum Masters pays itself back many times over. The Scrum Master is able to take their improved knowledge and apply it to their team which has a compounding effect. With the Scrum Masters fulfilling their role well the teams can hit their stride earlier and I can focus on key individuals and organisational issues.

In this blog post I explained my approach of providing direct feedback to Scrum Masters based on the Scrum Activity that they just facilitated. That approach has served me well; however it was not always been smooth sailing. I have learnt a few lessons along the way. From my successes and lessons I present to you a list of ‘Trys’.

The basic approach is to observe the Scrum Activities (Planning, Review, Retrospectives, Stand ups) and provide feedback directly to the Scrum Masters. Focusing on the Scrum Activities helps the Scrum Masters to quickly come to terms with the most visible aspects of Scrum. With these visible aspects under control, they can move on to learning about the more ‘behind the scenes’ aspects.

Prior to the activity

• Try asking for permission from the Scrum Master to attend the activity. This serves several purposes; it helps to bring the Scrum Master onside ready to receive your feedback, it gives you a chance to ask the Scrum Master to explain your presence to the attendees at the start of the activity, and it allows you to book in a time to provide the feedback promptly after the activity.

During the activity

• Try having the Scrum Master explain to the attendees as part of setting the scene for the activity; that your presence is to provide feedback to the Scrum Master and help them improve; it is not to grade the team. This goes a little way towards the attendees being more open in your presence.
• Try taking plenty of notes during the activity. Making sure to record specific examples of the incident that relates to the feedback you want to provide. i.e. During a Retrospective ‘Need to drill into symptoms to find root cause’, would be better recorded as ‘John said the tests where taking too long; you should have asked why are they taking so long, before getting the team to come up with a Try.”

After the activity

• Try to meet with the recipient promptly after the event. The same day is ideal, the next day is ok. With the event fresh in your minds you will both be better placed to discuss specific examples.
• Try keeping your feedback to around five key points or less. Any more then that will be hard for the recipient to take in during the feedback meeting. I often look at my page of notes and mark a couple of good points and a couple of the areas for improvement, making sure to only mark five points or less.
• Try meeting in private, this encourages the recipient to be more open and frank with you, especially when talking about their interactions with other people.
• Try starting the feedback meeting by asking them what they thought of the event; their answer is often enlightening. Some times they may already have internalised the feedback that you intended to give them, they may have seen the activity completely different to you, they may have had some insight into why people did what they did, they may offer up some issues that gives you a great opportunity to drill into.
• Try to discuss all criticisms in a constructive way. They should be presented as areas for improvement. E.g. ‘You did not stop the ongoing discussion about how to design the widget, that discussion was wasting the team’s time.’ would be better phrased as ‘The ongoing discussion about how to design the widget, could have been cut short and taken offline. This would have saved several minutes for the team. Perhaps next time a discussion is occurring that only involves a couple of people goes for over a minute of two, you could politely ask them to take it offline? Would you be comfortable doing that?’
• Try using the Feedback Sandwich:  

1. Start with positive feedback (Praise).     
2. Discuss areas for improvement (Constructive Criticism)     
3. Wrap up with more good stuff or general encouragement (Praise).

• Try to discuss all praise and criticisms based on recent and specific examples. E.g. ‘It would be good to see you support the voice of the quiet people in the team’ would be better as ‘When Ronald started to talk about his issues with the documentation being out of date; it would have been a great opportunity to support a quiet voice in the team by agreeing with him and asking the team to discuss it further’.

Good luck giving out your feedback and seeing your Scrum Masters grow. Let me know if any of these try's worked for you. I am also keen to hear about any that backfire for you.

Photo by: Kris Anderson

The benefits of time

I recently learnt first-hand the benefit that time brings, by that I mean how time for people to think through ideas and try it for themselves is crucial to success.

Usually when I give advice to someone, I spend a fair bit of my own time thinking about how they are progressing and generally worrying about the situation. My recent experience has shown that by do that I am doing myself a disservice.

The experience was as follows; a couple of teams that I had been coaching were both in tough situations for different reasons which I will not go into. I gave both of their Scrum Masters a couple of pieces of advice regarding some practices to change. Normally this is where I would have spent the coming days stressing about their progress and thinking of contingency plans. However some rather big impacts occurred in my personal life and work was the last thing on my mind. When I returned to work, I was surprised to find that both teams had achieved solid success with the suggested changes, all with no stressing on my behalf. I should not have been surprised; these were two very capable teams lead by intelligent and effective Scrum Masters.

What I took away from this event was that I need to allow more time for people to think about and trial new ideas before I check back in with them. In the mean time I can find other people and teams that I can help.

As a personal mantra: Plant the seed, don’t stress, just sit back and wait.

Photo by: Earls37a

Keeping track of great agile books

Helping others to grow, often has me thinking about which articles, books and presentations I should recommend for them to read. With the vast wealth of materials available regarding agile, Scrum and other methods I find that I some times lose track of the material that is most appropriate for people as they progress along their own agile journey.


A simple free tool that I have found that helps with this issue is Library Thing. 


This site allows me to easily list, rate, tag and categorise all the books that have read or am thinking of reading.  


A quick look at the members who have some of the same books as me revealed a few agile luminaries such as Bas Vodde and J. B. Rainsberger.


I can highly recommend signing up to Library Thing and having a look around.

Training vs Coaching

I am part way through reading ‘Coaching for Performance:GROWing human potential and purpose’ by John Whitmore. A key point that I have taken away so far is the difference between training and coaching.

A Trainer/Teacher instructs their Student on what and how they should do the new thing that they are learning.

A Coach will lead the student on a journey of self-discovery, aiming for the Student to become aware of the new thing that they are not doing, and then getting them to take responsibility for carrying out the new thing.

I have found that both training and coaching are useful approaches in my work. When the student is very new to subject such as agile; training works well to get them kick started and to secure a few wins, hence building their confidence. Once their foundation knowledge and confidence is in place, moving to coaching builds their awareness and responsibility which leads to long term success.