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.

A Creation Story

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.

LeSS is 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.

…But LeSS is not Minimalist: The Goldilocks Zone for Shu Groups

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.

Success with LeSS

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.

We’ve got a guest post from Ran Nyman who briefly reviews last weeks Certified LeSS Practitioner course:

Last week I participated Certified LeSS Practitioner course that was thought by Bas Vodde in Helsinki, Finland. Bas is one of the key persons behind the LeSS-framework, who has co-authored 2 and half books on the subject (The half if upcoming Large-Scale Scrum book that is not published yet). Before the course, I had spent time at reading already published books and draft of the upcoming book. The amount of material is overwhelming, and it was interesting to see how all the content can be compressed to 3 days course.

Overall impression was that Bas covered the relevant content in great detail, and some of the topics he just mentioned. This approach worked well since no one wants to see a slide show with five slides per minute and be overwhelmed by information overflow. Bas managed to select key topics to focus, so the training created logical whole.

I picked some themes from each day that I felt important from each course day. In day one we focused on learning and knowledge in an organization and what impacts on organizational design those have. In day two we started by defining products and how the definition affects LeSS adoption. Bas linked the Definition of Done as one of the key driver for LeSS adoption which was surprising. Day 3 we spent in great detail looking how LeSS works what structures it has and looking at steps that are needed to start LeSS adoption. One takeaway from this was that after having initial LeSS structure in place focus on the outcome instead of trying to form the organization to perfect shape.

I am strongly recommending this training to all doing or considering doing any format of Agile product development in large organizations since it will give you principles, framework and guides that will increase your success in it.

Last week, I finished the first Certified LeSS Practitioner course in Helsinki, Finland. It went really well I think. A lot of my training material is in a new order than I’m used to so that caused me to be somewhat uncertain about timing and things like that. Also the participants were probably above average in LeSS knowledge as some of them I’ve been working with for years (whereas some were quite new).

The first day, we focused on the LeSS overview and the LeSS principles. We also did some causal loop diagramming. One team decided to use it to ‘proof’ that offshoring was a bad idea but the further they went the better it started to loop. It wasn’t what they were expecting making it quite amusing. We also looked at feature teams and component team structures.

The second day started with some reflection and we discussed a lot about what the products where that people were working on. Mostly what the advantages and disadvantages were at defining product at a certain level (and how that impacts management practices). The biggest thing for this group was probably the creation of Feature Team Adoption Maps which caused long discussions about what steps the selected products would need to go next in their LeSS adoption. We discussed the Product Owner in-depth and spend time looking at changes in management practics and organizational structures when adopting LeSS.

The last day started off with the LeSS events and a discussion on how to deal with really large backlog items (with the concept of Leading Teams). We stil dived a bit into engineering practices and moved on towards adoption of LeSS in your organization. I spend about an hour sharing two case studies of LeSS adoptions with the group and the last day ended with ScrumMaster discussions.

All in all, I felt the course went pretty well. It gave me a lot of feedback on further improvement, but the feedback from the group was very positive. I’m excited about it and looking forward to the next course, hopefully in Melbourne. If you are in Australia, don’t forget to register for the course

Today, we’ve finally ‘released’ the site. Calling it released is a bit funny for us as we continuously deployed it, but we deleted the “under construction” sign :)

The last tweaks to the site were some big improvements in the front picture, navigation and some of the technical excellence content. Though, by far the most interesting tweaks have been the logo. We’ve iterated perhaps 100 different variants (thanks for your patience, Fred) and continuously asked people for different opinions and they constantly gave all different opinions. :) That said, I think the current logo is an improvement over earlier one and I’m liking it.

I’m typing this small post as I’m in the plane to Korea for a short training session. The last weeks have been amazingly busy yet exciting. The upcoming LeSS book is really shaping up well and this site also. It has been quite a struggle to get the design right and the content right. On the site, I don’t think we’re there yet, but at least it is good enough now and hopefully useful for people.

What’s coming up next? Still more work on the book. We’re getting to the end of this 2 year project. I should remind Craig about his statement of this being a short book project… Next year the LeSS trainins and working with other people becoming LeSS trainers. Exciting times.