Construction Accounting Software

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.

Rating: 3 / 5

As a management consultant to Fortune 100 companies, I’ve found this book to be a great source for how Lean principles help define what the authors’ describe as the Lean-Agile Enterprise. This book helps executives understand how to “see” flow of value through their IT/software program world. The authors give useful case studies that give clear examples of common industry patterns, that focus on efficiency at the component system level at the expense of being able to complete work for long periods of time. This classic hand-off/delay approach is hiding lots of waste in IT delivery organizations, and this book will help you see what’s really blocking you from achieving maximum results.

Through the different enterprise areas (Business, Management, Delivery Teams) the authors guide you through a new view of “flow” with specific principles and practices to help you get more productivity and quality out of your enterprise programs. They describe how looking at time through your delivery activities gets you to value faster and allows you to reduce waste and promote flow. This book has helped me understand often misunderstood Agile approaches by wrapping the activities in Lean principles.

From my perspective, Chapter 10 “Becoming an Agile Enterprise” and Chapter 11 “Management’s Role in Lean-Agile Development” bring executives a new way to look at technology delivery that includes valuable information on where to start, what to pay attention to, expectations, and how to involve the middle management layer in the process. Chapter 14 “Seeing Lean” may be worth the price of the book alone, because the authors give several experience reports on organizational challenges and how they were managed to get successful transition to Lean-Agile.

Rating: 5 / 5