Three New Books You Want to Read on Scaling, Strategy and Testing in Agile

I want to let you know about three great new books on agile you should read. Two of them are in the series I edit for Addison-Wesley; the third is by an author who previously wrote a book for that series.

Large-Scale Scrum by Larman and Vodde

“Large-Scale Scrum” by Craig Larman and Bas Vodde is great for anyone looking to scale Scrum up to medium and large projects. It provides a contrast to the very heavyweight Scaled Agile Framework (SAFe), and “Large-Scale Scrum” comes with its own cutesy acronym, LeSS. In fact the subtitle of the book is “More with LeSS.”

The book defines two scaling models. First is standard LeSS, which Larman and Vodde say is typically used for projects with around five teams. It can certainly scale beyond there. But for much larger projects, the book also defines “LeSS Huge,” which the authors report having used on projects with over 1,000 people.

The book is organized as you might expect with chapters devoted to key Scrum topics such as the product owner, the product backlog, sprint planning, reviews and retrospectives, and so on.

I found the book to strike a perfect balance between being overly prescriptive and too general. You’ll leave the book with plenty of advice on how to scale a Scrum project. But you won’t leave feeling hamstrung by having too many rules placed on your teams.

In fact, the authors include a nice summary of LeSS and LeSS Huge rules at the end of the book, and it covers only three pages.

Developer Testing by Alexander Tarlinder

Early in my career as a programmer, I remember coming across the phrase, “You can’t test quality in.” I read this in an article that compared 1970s and 1980s U.S. automobile manufacturing to Japanese automobile manufacturing.

The author was saying the U.S. car manufacturers were producing cars of lower quality than their Japanese counterparts because U.S. car manufacturers were trying to test quality into their products. Only after the car was built would they test to see if it was high quality. If it wasn’t, they’d fix defects (say a poorly fitting door) to make the product higher quality.

This was in contrast to Japanese manufacturers who built quality into the process. A later colleague of mine referred to this by saying, “Quality is baked into our process.”

Quality is not something that can be added to a product. Trying to add quality after the product has been built would be like adding baking powder to a cake after the cake has been baked. It doesn’t work.

Alexander Tarlinder’s new book, “Developer Testing: Building Quality into Software,” teaches programmers how to bake or build quality right into the process. The book starts with fundamentals (what is unit testing?) but also delves deep into more advanced topics like testing with mock objects. Similarly, it adds to the debate about testing state vs. behavior.

The book comes in at just under 300 pages, but is encyclopedic in what it covers. This book is a must read for every programmer, even those who are already doing a great job at developer testing.

Strategize by Roman Pichler

Most agile processes are empty of any advice on forming a company or product strategy. Product backlogs or feature lists are just assumed to exist or to spring spontaneously from the mind of a product owner or key stakeholder. In his new book, “Strategize,” Roman Pichler fills this void in agile thinking.

Roman is a long-time Scrum trainer based in the UK. He has previously written books about the overall Scrum framework and about succeeding as a product owner.

In “Strategize,” Pichler covers how to form and then validate a strategy, including identifying the right audience for the product and delivering just the features they need. The book covers roadmapping, including addressing the unfortunate misconception that because a team is agile, they don’t need to know where they’re headed.

Pichler presents a very helpful roadmap selection matrix that helps identify what type of roadmap is appropriate for different types of projects. I’ve already put this to use in discussions with clients. And I’m becoming convinced that if a company had a bad experience with roadmapping in the past, it was likely because of doing the wrong type of roadmapping. This book’s roadmap selection matrix will fix that.

This book should be read by anyone involved in determining the future direction for a product or entire organization.

What Do You Think?

Which of these books are you going to read next? Or, if you’ve already read any, please share your thoughts in the comments below.