Newsletter archive ( more newsletters )

LeSS Newsletter - August 2022

August 25, 2022

In this newsletter:

Welcome Back
Upcoming Warsaw LeSS Conference 2022
Previous Prague LeSS Conference 2021
Case study: Huge LeSS Huge at BMW Group — Autonomous Driving
Book Review: Software Engineering at Google: Lessons Learned from Programming Over Time
Learning Resources

Welcome back!

Huh. Why welcome back? Welcome back for three reasons.

First, most of the people on the northern hemisphere just finished or are about to finish their summer holidays. We hope you had a great time and welcome back!

Second, in most countries, the COVID restrictions are reduced or removed. COVID is not gone. It will be around but hopefully never in the same pandemic-way as it was the previous two years. I guess (I hope!) the coming years will be referred as the post-COVID years. We will go back to 'normal.' But what will that mean? Some companies and teams are eager to get back to the office as it is great to work with 3D people. Will we be fulltime in the office or will we end up with 'hybrid' working? How will that affect how teams function? What about the people that were hired during the COVID pandemic who live somewhere else? While we are back to normal, the new normal might be different than pre-COVID normal. How? That we will learn with the experiments to come in the next few years.

Third, there has not been a LeSS newsletter for a while. How did that happen? I (Bas here) shared in a previous newsletter that I'm usually the one coordinating the newsletter and that I moved country and joined a development team near-full-time. I have learned a lot from being a team member during COVID. The advantages of working from home such as less time spend on travel or more flexibility in time usage. But also the disadvantages since teams/zoom meetings are never as effective as a good interactive face-to-face meeting and team dynamics and team learning are very different in team when people are working from home. Frequent interaction remotely requires significant more effort and attention and team learning is much lower. The being a team-member experiment came to an end for now (although I'll miss my team) and I'm back more focused on sharing LeSS experiences... and writing this newsletter.

Upcoming Warsaw LeSS Conference 2022

It’s again this time of the year and we are excited to host another LeSS conference. After being in Amsterdam, London, New York, Munich and Prague, the conference will happen for the first time ever in Warsaw, Poland and not just any place, but right in the center at the historic location of the Palace of Culture and Science. We will return to a fully team-based full-scale conference. Already lots of people registered and we expect to get many more in the coming weeks. We have more than enough space.

This year’s program is almost completed and many speakers are waiting to share their talks and workshops with us. We will have experience reports like LeSS to scale Unicorns - experiences from Revolut and Uncapped, Betamax Vs. VHS, The Fundamental development pattern: Dreaming, Thinking, Doing, and How structure ate culture in a misused LeSS Huge at an Automotive Giant. There will be hands-on programming sessions like Concurrent Development in Practice and How to do a current-architecture workshop using less.works as the case. Additionally workshops like Sprint Review: Our tendency for irrelevant things and Does a Less Scrum Master need to be superhuman - Part II are waiting for your participation.

In his keynote, Bas will talk about Maximizing Dependencies with Interdependent Teams whereas Craig’s keynote subject is yet unknown - Likely he will surprise us, as every year, with deep insights and thoughts to occupy our marbles for a while. Besides many more sessions, we will have in parallel the Open-Space track where you bring in your own topics to explore them with others, check the full program here.

Some of the sessions will be recorded, however if you want to be sure that you hear about the topics you are interested in, you want to experience this unique team-based conference, meet the authors, and thought leaders, then come by and join us in this year’s LeSS conference in Warsaw. And btw, the kitchen told us that there will be plenty of tasty food (also vegetarian and vegan).

Previous Prague LeSS Conference 2021

On 16th September 2021, we had the 2021 LeSS Conference in the wonderful Prague. It was in a wonderful old monastery. Though there were still some COVID restrictions, they didn't impact the conference too much. Over all, it was really enjoyable.

Some of the recorded sessions from the 2021 LeSS Conference were:

Case study: Huge LeSS Huge at BMW Group — Autonomous Driving

BMW Early 2022 Konstantin Ribel and Michael Mai published the Huge LeSS Huge at BMW Group — Autonomous Driving case study. The authors portray BMW Group’s deep change from their 100-year-old traditional organisational design towards one optimised for making learning and adaptation easier in a large group. It is an in-depth examination of BMW Group’s LeSS adoption in the autonomous driving department, covering a timespan of mid-2016 until October 2019. A piece worth reading.

The case study is structured with multiple views (perspectives): (1) Timeline View and (2) Technology View.

The Timeline View starts with the background of and the motivation for the change. It continues with describing the preparation activities and structure before starting the first Requirement Area. Then, a new age enters the scene—the first Requirement Area—which is followed by expanding the change through adding more Requirement Areas accompanied by the happy and messy situations of the transformation. The retrospective on the Timeline View offers a thorough analysis of this undertaking. This view is concluded with a summary, positive effects and an outlook.

The Technology View characterises how the organisational design influenced the technology aspect and vice versa. It describes the journey from multiple products, hundreds of repositories, countless branches to one product, one repository, and one branch. Followed by a dive into software design and architecture, green build and communities.

Book Review: Software Engineering at Google: Lessons Learned from Programming Over Time

In this newsletter, I (Bas here again) would like to do a new experiment. I love reading to get new idea and learn what others are doing (or not doing). I also have the habit of writing an Amazon review for most books that I read (although I have a large backlog of reviews to write). So, I'd like to experiment with adding a book review to the LeSS Newsletter to give people some tips on great (or not so great) books which might be worth your time (or not).

The book review I'd like to share this time is from Software Engineering at Google: Lessons Learned from Programming Over Time by Titus Winters, Tom Manshreck, and Hyrum Wright. You can find the original Amazon review here.

I was skeptical about the amount of insight the book would give me. I've kept reasonably up-to-date on how google works through discussions with Googlers and published papers, so how much more insight and detail would this book provide. Turns out, I was wrong. This book is immensely insightful and contains a delicious amount of detail. A large amount of the problems (and solutions) they describe are common for all large-scale development and there is a lot to be learned for this book.

The book consists of 5 parts: (1) Thesis, (2) Culture, (3) Processes. (4) Tools, and (5) Conclusion. The last part (5) Conclusion was uninteresting and felt somewhat forced as there had to be some kind of ending. The first part (1) Thesis only contains one chapter about the difference between programming and software engineering. Although I'm not a fan of the phrase "software engineering," they did make in important point that software engineering includes time and scale. Chapter 1 also includes "Hyrum's Law" which didn't feel significant when I read chapter 1 but is repeated throughout the book. It states that dependencies are not towards its defined interface but towards the observable behaviour. That said, part 1 was a bit theoretical and not a good preview for the rest of the book. The majority of the book is in part 2-4.

Part 2 is about the Google culture and mostly focuses on teams, team collaboration, knowledge sharing, and the role of management. These chapters were interesting but not much different than other non-google material out there on the same subjects. Every now and then there were some good examples and stories that made it kinda special, yet these chapters didn't wow me. That said, the last chapter called "measuring engineering productivity" was more interesting... despite the title of the chapter. It described the internal engineering productivity team, what they did and how they worked. Especially the example on measuring whether code reviews were worth it was an interesting read.

Part 3 is called processes. Within this, it contains chapters on style guides, code review, documentation and a lot of chapters on testing. I enjoyed the chapter on style guides and how they work with these. The majority of this part is about tests which usually is a topic that I'd enjoy a lot but I felt there wasn't much news compared to what is typical described in the 'agile' testing world. That said, there were some insights such as their dislike of mocking and favouring fakes, or the descriptions of the higher-level testing. The part end with a chapter on deprecation and I did enjoy that chapter a lot. Deprecation is not an easy topic, it isn't widely covered in other books (that I know of) and is a typical problem that you will have in large-scale development. Towards this chapter and in the next part, for me, the book changed from "pretty good" to "excellent" or from a 4 star to a 5 star book.

Part 4 is called tools... which I feel is not a great name for this part as it isn't really just a description of tools (which would have made the chapter uninteresting) but it is very much about the details of the large-scale problems they had to solve and how they did that. The part kicks off with a chapter on version control which introduces Google's conclusion that they prefer a mono-repo. One code repository for all of google. With that also the "one version rule" everyone always uses the same version of the software. I've always considered these good practices but they are hard and take a lot of discipline to do well... The chapter describes really well what they do and why this is important for them, or actually probably for any large-scale development.

The next four chapters are (17) code search, (18) build system, (19) critique, and (20) static analysis were good, especially in describing the problems that they had and how they solved it. The amount of detail in these chapters was, for me, just wonderful. For example, the code search chapter covers the different ways you can do indexing and calculates the amount of memory needed and the amount of delay in the updating of the index.

The next two chapters were the best (IMHO), which were (21) dependency management, and (22) large-scale changes. Here again, the amount of detail and the thoroughness of the thinking was special. Dependency management reinforces why mono repositories are a great idea and then criticizes the current standard way of dependency management (semver). The chapter then gives a vision for how dependency management can be done completely different in open source... Basically always leaving the responsibility of fixing incompatibilities at the place where the change is happening. Chapter 22, large-scale change, introduces the problem to do large-scale change (or large-scale refactorings) in their mono-repo and introduces their large-scale change tool Rosie. In the past, I had heard that they were able to do these large-changed but never fully understood how they did it (as it is a hard problem!). But this chapter left me putting the book down at times to just say "wow" and be amazed at how they did that. Again, the devil is in the details and those devils are all covered, such as, how do you cope with code reviews in large-scale changes.

Chapter 22 and chapter 23 were on CI and CD, which were interesting but the last chapter, chapter 24, was the cherry on top. It was called "compute as a service" and describes how google gradually build up their deployment environments (cloud). How they moved from machines to virtual machines to containers. It also fills in some of the detail left open on how it is possible that they can use their massive infrastructure for things like code search, building, static analysis, and testing. Again, repeating myself, the amount of detail and stories given made it excellent.

The book started theoretical, then went to pretty good but relative standard and when, in the second half, to lots of details and insights that made me several times go wow. Virtually all of the problems that Google had to solve are applicable to the majority of large-scale development. Their insights and thinking should benefit anyone involved in large product development. Unfortunately (or probably fortunately) you won't be able to copy exactly their solutions due to the different context. But with the insights that this book provides, you do not need to make the same mistakes anymore. This book is a must read for anyone in large-scale product development for probably the next 10 years. Thanks to the authors for writing it and sharing so much detail. 5 stars.

Learning Resources

Here are some new selected learning resources and experiences. There is more on the LeSS Youtube channel, and on the LeSS site articles and videos section.