Lean-Agile Software Development: Achieving Enterprise Agility [Anglais] [Broché]

Lean-Agile development was a book for which I had some expectations, at least that it would contain some new ideas or viewpoints. My first observation was that it wasn't very thick, but that is perhaps positive. In the end, I was disappointed. The book did not bring much new things, the target audience is unclear to me, and at points contains... what I would consider misinformation. Let me dive deeper.

The book is part of the NetObjectives book series. NetObjectives is a training company, thus the book frequently promotes their training (slightly annoying). The book consists of three parts, first "Extending our view beyond projects," second "Lean project management," and last "Looking back, looking forward." However, while reading the book, I couldn't see a very clear distinction between these parts.

In the introduction, the authors talk about how Software development processes over time swing from too little to too much, I'm not sure I'd agree with that as both too much/too little have been evolving at the same time. Next, the authors discuss principles and paradigms and define the core beliefs of Agile development, lean and waterfall--or should I say... what the authors think is the core belief.

The first chapter provides some lean/agile principles, but assumes the reader is already familiar with a lot. The second chapter provides benefits of agile development... the selling agile chapter. In the next chapter, the authors insist on boxing Agile/Scrum to only the project development and claim that lean development covers the whole track and thus is more suitable for enterprise adoption. Chapter four discusses "Lean Portfolio Management" and was one of the least clear chapter (to me). The level they were talking about was unclear to me and it gives a general concept, but not too much details. Interestingly enough, neither do the authors refer to other material written on portfolio management. Their point seems to be that you should not manage projects, but instead features (MMFs). Though, then they show (figure 4.13) a story-point burn-up, which is great... but they never clarify how you can draw a story-point burn-up across multiple projects and products (as the points need to be synchronized) or... perhaps more essential... what the purpose of such a chart is related to portfolio management.

Part 2 discusses Lean Project Management. The first chapter described why Scrum is "not enough" and has some drawbacks (or, the Scrum that the authors understand). Then Kanban is introduced as an alternative to Scrum, even though most of the book still seems to assume iterations and Scrum. The next chapter discusses Iteration 0 which came as a surprise to me as the next chapter is release planning (why this order?) The Release planning chapter felt somewhat basic. Next chapter was is about visual controls. The most amusing thing about this chapter is that there are no pictures whatsoever of real visual controls! There are drawings, but no pictures. Chapter 9 is "the role of QA" in which the authors vaguely describe that QA needs to be moved up-front, but then don't get into very much practical tips. Next chapter discusses how to transition the whole enterprise to agile development, where it simplifies all companies in three categories: Product, IT and product-IT companies and provides the obstacles this kind of organization need to resolve. Chapter 11 discusses management role in Agile where the authors attack Scrum and "the agile community" (without saying whom specifically) and state that lean is better because that takes managers into account. Chapter 12 discusses coordination between multiple teams using a Product Coordination Team (which I would definitely not recommend myself) and the last chapter of part 2 has three pages about design and architecture.

Part 3 is just one chapter in which the authors divide the world of lean into "Lean science," "Lean Management," and "Lean Knowledge stewardship." I'm unclear on what the purpose of doing this is and know that I've never ever seen this ever in any other book related to lean. Next, it discusses in a few case studies (each half a page long) of applying lean-agile.

Why didn't I like the book? I gave a couple of criticisms at the start of this review, and like to clarify these.

It is unclear to me what the target audience of the book is. The book assumes a lot of basic knowledge (this is not a book for people new to Agile). It assumes knowledge about TDD, understanding of Scrum, understanding of other agile practices, etc. But then again, the book doesn't provide in-depth new information either. For example, if the book is not targeted for people new to Agile, then why would it have a chapter on "benefits of Agile" or a chapter such as "Iteration 0" which provide nothing new to a person already experienced with the basics. Furthermore, the book covers information really shallow, it mentions things but doesn't go deeper into the topics. A person with basic agile knowledge is likely to already know that shallow information and is looking for more experience, stories, and practices to try out

Then some misinformation. Of course, this is my opinion but based on other literature available. A simple example example is the role of Deming. No doubt a great person, though the authors state "the Toyota production system was built on his ideas." However, according the book Birth of Lean, which describes the creation of the TPS, there was not much (perhaps no) influence of Deming. Another example, in the introduction the authors state the popularity of 4GL tools in the 80s... whereas they mention that the 90s is "an upsurge in rigorous process" where the authors seems to ignore Rapid Application Development and the work of James Martin during the early 90s, which popularized 4GL tools. Last example, perhaps more serious. In the drawbacks of Scrum, the authors state "teams should be comprised of generalists." I think I'm reasonably familiar with Scrum, but doubt that every team should be composed of only generalists. It seems to me to be a misunderstanding of the author of Scrum...

Last criticism. When reading this book, I did not get the feeling the authors have much experience about the subjects. Why? There are not that much stories of their experience in their book and the stories that they tell are about people who joined their training. The authors rarely go over some shallow overview of concepts, into the practices or concrete examples on how to implement these ideas.

In short, I would NOT recommend this book. There are better books on Agile and Lean development (e.g. books of Poppendieck, Cohn), this book doesn't add much to them.

I've been doubting about the rating for a long time, on whether it should be 2 or 3 stars. I decided to go with 3 stars, because... despite all the criticism above, the authors do describe useful concepts and important ideas and most of their book is not wrong, it just doesn't go very deep.

Shalloway's book on lean and agile development is an excellent introduction into a subject that deserves much more attention from the mainstream, namely the introduction of lean principles and techniques into software delivery.

The book covers a wide range of topics, and while I would have liked to see a lot more detailed paid to certain sections (ie portfolio management), I think this book serves it's purpose, to provide readers with ideas on how to supplement and even supersede agile techniques with lean thinking. Alan spends some time discussing the benefits of Agile, but has the courage to criticize some of the limitations of traditional agile concepts. Alan gives good introductions on kanban, value stream mapping, 5 why's, and other techniques.

I was able to use much of the material in this book as a basis to introduce lean to my clients, and found it very useful for doing so. Read this book if you are looking for a fresh perspective on how to improve business outcomes through better software delivery.

Este livro revela as raízes do pensamento Lean no desenvolvimento ágil de software. Faz um paralelo com o framework scrum e, através do pensamento crítico, ensina como torná-lo ainda mais efetivo. Transpõe a dimensão de projeto, tratando da visão de portfólio, do gerenciamento de produto e da agilidade em nível corporativo.

Uma leitura incrível que prende a atenção do início ao fim.