I just noticed that the last time I wrote about LeSS was three years ago. And much has changed in this time. I was writing a blog post (available here – in Polish, but I guess translators can help) after a significant change we made to one of the company’s products.
Back then, I was a self-taught LeSS enthusiast in need of ideas on how to organize the work of a couple of teams around a single product. I heard about LeSS being implemented in another area of the company. I talked to the other guys, did research, a lot of reading, and simply implemented the process. It worked.
The Training
A couple of months later, I went through proper LeSS Practitioner training conducted by Jurgen De Smet. What I learned there (and how I learned it) made me realize the true priorities of a genuinely agile approach. The training itself lasted four days, and for most of the time, we didn’t even talk about how the LeSS process looks. Instead, we went through the 10 principles (full list here). At the end of our training, we, the participants, were preparing a software development process on our own that would include all the principles. All groups ended up with something very similar to the process described as “by the book” in LeSS documentation. None perfectly matched the original idea of LeSS organization, but thanks to using principles as acceptance criteria, all of them had a high chance of being really valuable if used in the real world.
Thinking Begins
Naturally, that made me wonder about how I implemented LeSS, about all my work with agility before, and how focusing on the process could be risky when not remembering the values and principles behind it. How to get people “on the agile board”. How putting the product in focus solves a lot of issues, and finally… how simplifying things is difficult. Especially the simplification thing made me wonder, as I still don’t have the answer to why people tend to build complex systems around complex issues (which is, in general, the nature of software development). If I can do math properly, that just adds complexity instead of helping.
Outcomes
Even without the answer to why things are made more and more complicated, the LeSS approach radically changed the way I work. For the last three years, I’ve been way more open to experimenting with different approaches when doing Agile Coaching. And that pays off. My way of dealing with things now usually starts with asking a million times “why?”, setting some goals, with some principles in mind, and whatever comes out of it is validated by value AND fits the ways I’d like to see it.
Examples?
Starting cooperation with another Agile Coach? Let’s create a contract for our cooperation based on Agile manifesto principles.
A team contract required? Let’s set a clear goal on why to create it – base it on Scrum values like cross-functionality focused on customer-centric value delivery (a topic for another, long post).
Company values need reshaping? Remember to include transparency and/or learning in your workshop.
Such an approach makes preparing initiatives, changes, and workshops relatively easy. In each of the mentioned activities, the flow looked a bit like this:
Assess the root cause > search for adequate principles in frameworks > design how you’ll work with the issue
And I know – LeSS was in the title, you might have expected more about the framework itself. But LeSS is already so well-documented that I wouldn’t have more to add – instead, I like to share a bit more about the additional values taken out of it.
Can you share some interesting outcomes that came far beyond the original purpose of your trainig of experience? Feel free to share.
Leave a Reply