Cross-posted. Find the original at the SolutionsIQ Website at this link
Thanks for taking the time to read (and watch) this introduction to LeSS (Large-Scale Scrum)!
If you prefer video to text for an introduction to different aspects of LeSS, please take a look at these videos at the the LeSS website less.works. From that list, a good video to start with is Introduction to LeSS (short video) – Craig Larman.
Where does LeSS come from? In 2002 I wrote the book Agile & Iterative Development: A Manager’s Guide. At that time many people “knew” that you couldn’t scale agile development. But from my experience within Valtech — that does outsourced development, and where I worked — we could see that it was possible. And I started to get requests from clients to apply agile concepts and especially the Scrum framework — as an early-days Scrum coach starting in the late 1990s, and early Certified Scrum Trainer — to large-scale development. This eventually led to work with groups such as Ericsson, UBS, Bank of America Merrill-Lynch, JP Morgan, and and Nokia Networks, among many others. (By the way, Nokia Networks is the telecom infrastructure group, not the Nokia mobile devices group eventually bought by Microsoft.)
You can read more about some of these client experiences at the LeSS case studies site.
A key thing to appreciate about LeSS is that it wasn’t created on “on paper” or in theory; it came out of our experience working with many clients since 2005 who have been adopting large-scale Scrum.
While at Nokia Networks in early 2005 it was a great pleasure to meet and start to work with my friend Bas Vodde, who is the co-creator of LeSS. Bas played a key role in helping groups adopt large-scale Scrum at Nokia Networks, as part of their internal “Flexible Company” team, and was also a member of the leadership team of a large (roughly 1,000 people) multi-site product group that was adopting LeSS. So Bas had a tremendous amount of in-depth long-term experience in introducing and doing large-scale agile development, from debugging large organizations to hands-on embedded systems development. He wasn’t a classroom teacher or someone who just spent a few days in a management meeting talking about scaling. He was in the trenches doing this for years. And he has a wealth of insight into systems thinking, modern management principles, and agile and lean systems, including Scrum (as he is also one of the early Certified Scrum Trainers).
Bas was and is a great complement to my coaching and consulting with scaling agile development, and I’ve learned a lot from him. And we’ve both learned a lot from our customers adopting LeSS over the years. So we ended up collaborating as partners in coaching and communicating about LeSS, starting with the first LeSS book we wrote in 2007, based on our experiences with customers, Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum. This was followed by our 2009 second volume on LeSS, Practices for Scaling Lean & Agile Development: Large, Multisite, and Offshore Product Development with Large-Scale Scrum. And now we’re completing our third book on LeSS, which is a simple primer to help people successfully get started, Large-Scale Scrum: More with LeSS.
If I had to boil down a description of LeSS to something really short, one thing I’d say is, “LeSS is relatively small and simple.” You see, I have a background also consulting and coaching in the 1990s with the RUP (Rational Unified Process). One of the key insights I got from that experience is that frameworks with a lot of definition and “prescriptiveness” don’t really work in terms of large-scale adoption. They aren’t contextual enough. They inhibit empirical process control (a key Scrum principle) and the unique learning and exploration which must take place. Development groups (and the work of development) are just too varied for anything like a detailed highly-defined framework or process, or much of a standard recipe. Now, the RUP tried to counter this concern with the idea of “tailoring down” or deleting elements to make it ostensibly simpler. That sounds fine in theory, but I saw in the real world that it just didn’t work. Groups ended up “adopting” too many roles, structures, processes, and techniques and becoming overly ‘defined’ and complex. Even though they were advised to “only take what you really need from the buffet of options.” And people in these groups had the assumption that they could delegate or avoid the learning, discovery, and resolution of their systemic weaknesses because “the problems are solved by adopting the framework we’ve bought.”
But here’s something we’ve learned: more defined process leads to less learning, and conversely less defined process leads to more learning.
Now, the logical conclusion of “less defined process leads to more learning” is to adopt essentially no defined process or framework, or as a variation, to adopt a system with only a few simple principles. For example, there are ‘systems’ such as the Learning Organization movement, which recommends systems thinking, personal mastery, mental models, shared vision, and team learning. Who can argue with that? These are great principles!
But… run this experiment: Go to a telecom infrastructure product group of 500 people in 5 sites, that has been working a very traditional organizational design and culture for decades so that the old system is really baked in, all the way through people’s brains. Or likewise in a bank. And then say, “Hey folks, do this: systems thinking, personal mastery, mental models, shared vision, and team learning!”
Nothing really changes.
And that’s a second thing we’ve learned over the decades being involved in change initiatives: For a group that is in the beginning-adoption phase of a major change, they need a certain critical mass of concrete advice about structure, policies, processes, roles, and so forth, in order to actually do something about the change. Otherwise, if it is a “Shu phase” (the beginner-learning-fundamentals phase) group with strong traditional elements, either they don’t really change anything, or because of strong status-quo forces that resist change, then the change is ‘faked’ in some way to superficially conform to the change, but when you scratch below the surface, it’s the same old system. By the way, often that faking is done by redefining or overloading the new terminology to mean basically the same as the status quo.
So, there’s a Goldilocks zone for a modern development framework for a Shu-phase organization, in between “just a few simple principles” and “lots of roles, structures, techniques, and processes.”
We observe (and many others have observed) that regular one-team Scrum is very much in that zone, for a small product group. Its simple concrete elements provide just enough definition to enable its deeper principles to be realized: empirical process control with transparency, self-organization, and so on.
And similarly LeSS (large-scale Scrum) takes this same theme: just enough concrete elements for a Shu-phase organization to make real changes and know what to do to get started, to enable the deeper principles of empirical process control with transparency, and self-organization. But it’s just barely enough. There’s vast space in LeSS for the unique situational learning and adaptation that is required for the myriad and unique organizations. LeSS Focuses on Root Causes in the Organizational Design
Also, in boiling down a description of LeSS to something short, I’d say, “LeSS focuses on the root causes of organizational weaknesses when scaling.” Many organizational-design experts know that key root-cause problems include (1) the existing status quo organizational structures and roles, and (2) command-and-control policies that deny the reality of inherent variability and human motivations in development work. But similarly, many experts or consultants tip-toe around these issues and avoid raising them, because they challenge status-quo power structures and beliefs. That’s another reason why “fake change” happens. Change is only allowed up to the point that it challenges or interferes with status quo roles, power structures, and policies…. “Well, you programmers are welcome to adopt this scrum-thing. Do whatever you want to be more efficient. But make sure it’s all done by your committed delivery date!… And the project managers will be measuring you to ensure you’re on track.”
Of course, any “change” introduced into such an organization will just be a superficial layer of new terminology and techniques on an essentially un-changed system…
BEFORE, TRADITIONAL: UX analysts write up an Experience deliverable to give to others, Business Analysis team write use cases and hand them off to programmers, Architects define UML PowerPoints and push their designs to programmers, programmers write code for the testing group to test, after it’s been integrated by the Integration Manager, etc.
AFTER, ‘AGILE’: Agile-UXers write Experience Stories for others to read, Agile-BA teams write user stories for handing off to programmers, Agile-Architects define Architectural Epics and push their designs to programmers, programmers write code for the Systems Team to integrate and test, etc.
Really, what’s changed?
But the good news is that LeSS doesn’t skirt around these key issues: it directly addresses the root cause organizational design issues that are at the heart of systemic weakness when scaling: myriad single-function teams handing off WIP deliverables to other teams, the Contract Game, command and control management, entrenched status quo positions, and so forth.
Of course, there’s more to understanding LeSS and adopting it than this brief article has touched on. A great way to get started is with the Certified LeSS for Executives or Certified LeSS Practitioner course (see course listings), reading and seeing videos at the less.works website, working with a coach who has hands-on experience with LeSS (see coaching companies), and reading the three books on LeSS. LeSS is simple but powerful, and we want to help you succeed with your adoption.
RSS feed