Another Large-Scale Scrum Training (CLP), taught by Craig Larman in NYC, is in the CompuBox.
More than thirty people from all-around the globe (North America, South America, Europe) came together for this brain-jelling learning experience! The group consisted of product owners/managers, software engineers, managers and organizational design consultants (scrum masters, coaches and trainers) – people coming from different backgrounds and with a focus on different aspects of organizational agility. What has united them all, however, was their eagerness to learn in-depth about principles of organizational design and implications of Scrum adoption at scale in complex organizational settings.
Course Highlights
With exception of a few rare questions/clarifications, the class spent NO time discussing basic Scrum. It was implicit (assumed) that everyone in class had strong knowledge and hands-on experience with the basic framework. On occasions, the topics discussed would bump into “…oh this is not even LeSS-specific; this is just basic Scrum…” but those cases were rare.
Not until day three,is when the class took a deeper dive into LeSS Framework and LeSS-specific events, artifacts, roles…. Why was not it done sooner? Well…
- LeSS is Scrum. It is the same very Scrum described by Ken Schwaber and Jeff Sutherland in the Scrum Guide, but done by multiple teams, as they are working together, on the same product, for the same product owner. LeSS is not “…something that IT does, that is buried in a company’s basement, under many layers of organizational complexity…”. LeSS is an organizational design that uses Scrum (team) as a building block. Understanding basic Scrum made understanding of LeSS very easy for everyone.
- The class was made of people that have completed all assigned homework (self-study), before attending. People knew what LeSS picture looks like ?, when coming in. Everyone in class was an educated customer. Importantly: there were no attempts to change LeSS (or change training content ? of LeSS), to make it better fit conditions of organizations, where people came from.
- Spending the first two days on understanding system modelling techniques, differences between causation and correlation (as well as other dynamics) among many system variables, made full understanding of LeSS on day three, come more naturally.
The class learned how to see ‘the whole’/full picture of organizational ecosystem and learned to appreciate why Organizational Design is the first-order Variable that defines System Dynamics (followed by everything else: culture, policies, norms, processes, etc.)
One of my (Gene) biggest take-away points (on the top of an excellent LeSS refresher, from Craig himself), that I plan on using immediately, was the fact from history that was discussed at the beginning of the course (and, sadly, forgotten or known known by many). And it goes as follows:
…Back in 2001, at Snowbird, UT, where the group of seventeen entrepreneurs-product-developers have met and came up with what is known today as ‘Agile Manifesto’, the two contending terms to-be-used were adaptive (suggested by Jim Highsmith, the author of Adaptive Software Development) and agile (suggested by Mike Beedle). ‘Agile’ won because of the reasons that are described here. Truth be told, because the English meaning of ‘agile’ is not as intuitive is the meaning of ‘adaptive’, today, there is a huge number of fads and terminology overloading/misuse that make the original meaning of agile so diluted and abused…. As it was meant to be: Agile == Adaptive ==Flexible. We all have to be careful with the meaning of words we use, to avoid this painful irony?.
Here are some Kodak moments from the event:
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
I was given a disclaimer when initially signing up for the CLP training that I could not fully grasp until having gone through it with Craig. The disclaimer was that there might be ‘brain-damage’ from the training. While I am happy to report that did not happen in the literal sense, there was certainly a lot of rewiring or ‘brain-jelling’ as Gene has put it. After spending three days with Craig, you certainly gain a different perspective on things. The facilitation of the training really lets you walk away ‘owning’ the understanding rather than ‘renting’ it. This is a big part of why the rewiring is feasible.
One of the key takeaways that I walked away with was to always be reminded, “don’t lose the plot.” Coming from a large organization, this is an essential piece of advice for anyone looking to make meaningful and impactful changes. You must set clear system optimization goals, and stick to them. It is all too easy to fall into a local optimization mindset and make a decision because something seems like the more efficient or faster way to do things. However, when reminded, “don’t lose the plot,” you can point back to your optimization goals and clearly see that the more efficient or faster way is not consistent with your goals. In my experience, losing the plot is the main driver of local optimization. Now having gone to the training, my brain has been rewired to recognize that these are patterns and to take a step back rather than acting on them to look at the entire system including the optimization goals to gain a full understanding of the real impact of an organizational decision.
I came into this class anticipating learning about LeSS. What I discovered was so much more than a new scaling framework. Most of the time during these 3 days was dedicated to learning causal loop diagrams to solve organizational puzzles. To Agile coaches and change agents in the room these puzzles sounded painfully familiar:
“We don’t have time for creating clean code, because we are too busy building features and fighting fires caused by our existing code.”
“We have one product and many teams; each team has their own product backlog prioritized by their own product owner. Because this is more “efficient” and “productive”.
“We are scaling agile. Therefore we need “agile” portfolio management”, etc.
As we modeled the relationships between different variables in these puzzles we became utterly aware of our cognitive bias and began to realize the ineffectiveness of our own local optimization efforts. These realizations were so vivid and pronounced that a number of people in the class (myself included) found themselves feeling emotionally disturbed at times.
“What is your system optimizing goal?” This question kept coming back in conversations and debriefings as we were learning more about the systems thinking. This eye-opening approach triggered many discussions. A few of us were contemplating organizing Causal Loop Diagram Dojo to continue practicing and getting better at it. Stay tuned for more info on this one!
Being a trainer myself, I also picked up a few pointers from observing Craig Larman’s class design, his training and time management style. The class was designed with mathematical precision and ran from 8:30 AM until 6:00PM. On. The. Dot. And have I mentioned the 7 min breaks and 37 min lunches?
I was happy to see a number of brain-friendly activities included in this class. We built a mindmap skeleton on a wall at the beginning of the class and kept updating it periodically with the new LeSS topics as we were learning them. We had a number of “read-draw-teach back” exercises, engaged in pair-shares, standing retrospectives and captured our Aha! Moments at the end of each day.
In just one week after the training, I found myself referring to it many times in Agile transformation conversations at Hudson’s Bay Company as well as at the December meetup of NYC Scrum User group.
Should you attend the next LeSS training? It depends.
The blissful ignorance of local optimization or painful truth of systems thinking – what is your system optimizing goal?