
Average Reviews:

(More customer reviews)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.
Click Here to see more reviews about: Lean-Agile Software Development: Achieving Enterprise Agility
Agile techniques have demonstrated immense potential for developing more effective, higher-quality software. However,scaling these techniques to the enterprise presents many challenges. The solution is to integrate the principles and practices of Lean Software Development with Agile’s ideology and methods. By doing so, software organizations leverage Lean’s powerful capabilities for “optimizing the whole” and managing complex enterprise projects. A combined “Lean-Agile” approach can dramatically improve both developer productivity and the software’s business value.In this book, three expert Lean software consultants draw from their unparalleled experience to gather all the insights, knowledge, and new skills you need to succeed with Lean-Agile development.Lean-Agile Software Development shows how to extend Scrum processes with an Enterprise view based on Lean principles. The authors present crucial technical insight into emergent design, and demonstrate how to apply it to make iterative development more effective. They also identify several common development “anti-patterns” that can work against your goals, and they offer actionable, proven alternatives. Lean-Agile Software Development shows how toTransition to Lean Software Development quickly and successfully
Buy cheap Lean-Agile Software Development: Achieving Enterprise Agility now.

No comments:
Post a Comment