Notes on LeSS with Craig Larman

I was very lucky for Craig Larman to be my fellow traveler in my Agile journey in April 2016, although for a very short period of time. I had the honor of taking part in LeSS practitioner course offered by him. I immensely enjoyed learning from one of the Agile Gurus, not only about LeSS but more importantly about Agile. I have heard stories leading up to the Agile Manifesto meeting at 2001, philosophies behind defining Scrum and why things have been named the way there are now. My mind has officially been blown. It completely reignited me to learn more and try new things while not forgetting the principles. Notes below is the ones I took at the course. It was the first time that it has been offered in Canada, thanks to Bertieg.

This is the big picture of LeSS. There are lots of details in the picture. You need to pay attention to all the details. For example, there is one scrum master that is helping with two teams and there is a team with a dedicated scrum master.

And this is my first attempt at describing LeSS to one of my colleagues.

System Thinking is one of the principles of LeSS. I found it very useful. You can use this method to get people to find the causal links between different parts of the system (I am sure there is more to that). You want to utilize correlations as a conversation starter to identify the causal links. This will help understand the system better and how the change will best take place.

System model -> causal link ; Correlation -> causation then model

Contract / Commitment game is a great way to show what Agile should be all about, it is not to change titles and just claim to be Agile.

This is an attempt to have the Team Adoption Map built for the LeSS team. This will work as a diagnostic (i.e. metric) on where we are right now and where we want to be in near future. Keep in mind that we are talking about all the teams and not individual teams in LeSS.

• Do you know what is the first book with Agile in the title? Agile Software Development by Alistar Cockburn. You want to learn more about Agile and its history, you need to read this book.
• Software creation is a learning process, coding which is a side-effect of. 
• What LeSS helps with is to descale organizational complexity.
• Bonus has no value -> has been removed from LeSS
• On the question of what are the criteria of adopting LeSS for an organization: Most organizations should not adopt Agile, it will harm them more than it helps them.
• A great way to build cross-functional team: more skills, more money => motivation
• On why Agile has been chosen Agile in 2001: Agile is selected to mean Flexibility and Adaptive, not faster! 
• Contract negotiation in Agile Manifesto was an internal contract when originally talked about
• Organizational debt: organizations with process debt not code necessary
• Reinforcing loop , the game 
• In a Feature team, all groups are dissolved (You are special but not that much special). All managers are dissolved as well.
• There are job safety and salary safety but no role safety in LeSS.
• In the Informed session, communication plan from leaders needs to be addressed. 
• Look for an old unused title in HR that can be used as a general one (don’t wait for of chart change) 
• You can have Internal title and external title for a role.
• Scrum note: deselecting is for the team to decide, firing is a legal aspect.
• LeSS is Multiple team scrum v.s. Multiple scrum team.
• Coaching Tips
• On the topic of MVP and shippable product: I think you are confusing feature rich enough with a shippable product (a side lesson for coaching (confusing v.s. confused, context))
• I table that for now -> Lesson for coaching
• A coach himself should be free from all jargons -> Lesson for coaching
• Prime Factorization Table, a great TDD example
• It will take 4 to 5 years of a norming team to become a high performing team – Tuckman model
• Interesting Topics To Learn:
• Pico Meta-Analysis
• Tony Buzan is the creator of Mind Map, it will be interesting to read upon his initial idea of Mind Map.
• Evidence-based management from MIT
• W. Edwards Deming and his theories
• Laws of system thinking
• Nemawashi
• Queueing Theory: describes bottlenecks
• The New New Product Development Game
• The 5th discipline, MIT
• Business without bosses, Book
• Leading team Hackman, Book
• How to measure anything, Book
• Maverick organization no boss, Book
• Interesting Quotes
• Organizational change goes better with Alcohol
• So-called portfolio managers are similar to cancer therapist 
• Culture follows structure (in startup is vice versa) 

• Interesting Videos
• Forbes 10 under 10
• The expert video YouTube 

Test Driven Development

• TDD is not about testing
• clean code
• executable specifications
• micro-design
• tests in TDD are as equally important as the code
• -> change name (refactoring)
• ->don’t make me think as a programmer
• google code smell comments for how bad is commenting
• add a comment for an empty list and then show the value of the code:
• Array.listOf (or so)
• collections.emptyList
• Refactoring I- n there 

How to introduce LeSS in an organization? This is a high-levels understanding of min from Craig’s discussion.

1. 300 page to read
2. Mob with dev half day
3. Product team half day conversation
4. Informed consent session with all
5. 1-monthh delay
6. prep (2 months for Craig)
1. DevOps
2. Knowledge Gap
3. Logistical
4. Finding Good SM
5. Workshop for preparation (Liftoff) usually 3 days
7. A Story of Self-Designing Teams
1. for (2-3 cycles)
2. {
3.    10 minutes team select 
4.    gap analysis
5. }
8. SM hired by the team (First 3 months no SM, for first LeSS adoption, Team has only itself to rely on)
9. In LeSS there is no room for manager
1. -Bank needed a line manager, some cases are exceptions
2. -People have to hire their managers

Any intermediate documentation from lean thinking is over-production and waste. There are two kinds of waste in Lean, Muda type 1 and Muda type 2 (or Pure waste & Temporary necessary waste)

• There are several ways to optimize the system 
• Return On Investment h
• Business value h
• Cycle time h
• Market share h
• Keep people busy h
• You need to know what you are optimizing for if you are an organizational design change agent.

The functional team and local optimization. Imagine each F are a functional area. The teams set up to have specialized people from the needed area based on the project need. 

Business cases and how they are going to be optimized based on people being busy. You can easily see least value business case will have an impact on the most important value one just because to keep a person busy.

Expanding product definition is a good way to start continuous improvement at the organization chart Level.

How to descale a product and make it small enough to be worked on as a LeSS team with multiple feature teams.

Complication of one Feature Team experiment. This is if all of the people are working in a role and not all of them are developers. Craig ran an exercise and asked us to think of why is it not effective to have such setting.

It was awesome beginning every session with some exercise. A great mind resides in a healthy body!

If you are interested in learning more about LeSS and most importantly thoughts behind that from Craig, I would highly recommend watching his 2012 Keynote speech.