| | |  | Lean Software Development | Home » » » » Lean-Agile Software Development: Achieving Enterprise Agility | | | | | | | Description: | | 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 to -
Transition to Lean Software Development quickly and successfully -
Manage the initiation of product enhancements -
Help project managers work together to manage product portfolios more effectively -
Manage dependencies across the software development organization and with its partners and colleagues -
Integrate development and QA roles to improve quality and eliminate waste -
Determine best practices for different software development teams The book’s companion Web site, www.netobjectives.com/lasd, provides updates, links to related materials, and support
for discussions of the book’s content. | | | Product Details: | | | Author:
| Alan Shalloway | | Paperback:
| 304 pages | | Publisher:
| Addison-Wesley Professional | | Publication Date:
| November 01, 2009 | | Language:
| English | | ISBN:
| 0321532899 | | Product Length:
| 9.24 inches | | Product Width:
| 7.1 inches | | Product Height:
| 0.63 inches | | Product Weight:
| 1.05 pounds | | Package Length:
| 9.2 inches | | Package Width:
| 6.9 inches | | Package Height:
| 0.8 inches | | Package Weight:
| 0.95 pounds | | Average Customer Rating:
|  based on 8 reviews |
| | | | Customer Reviews: | |
Average Customer Review:
 ( 8 customer reviews )
Write an online review and share your thoughts with other customers.
Most Helpful Customer Reviews
26 of 33 found the following review helpful:
 Shallow and unclear audienceNov 28, 2009
By Bas Vodde
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.
1 of 2 found the following review helpful:
Informative and InsightfulJun 20, 2010
By Jeff Anderson
"Agile Lean Evangilist"
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.
2 of 5 found the following review helpful:
 This is the best book I have read on helping companies truly achieve enterprize agilityDec 12, 2009
By Randy Ripple
"Management Consultant"
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.
5 of 10 found the following review helpful:
New Gold Standard for Software DevelopmentNov 30, 2009
By John Passacantando
When I was running one of the largest environmental activist organization in the country, we often struggled with how to align our technology needs with our mission. Shalloway, Beaver and Trott have the answers. After reading their book I finally get how simply paying attention to their "Lean" principles (thus illuminating prioritization and work flow) can free technical teams and their partners from thrashing due to their giant to-do lists. Our technical guys were always overloaded.
Organizational multi-tasking is not only wasteful, but it creates lack of focus. This book will teach leaders how to drive their vision top-down, and show them that if they insist on visual line-of-sight, they, or their managers, will see with clarity and enable their organizations to focus on the most important activities each and every day -- like stopping global warming!
Chapter 3 (The Big Picture) opened my eyes to how Lean thinking shows us the challenges of organizing technology by skillset, and Chapter 4 (Lean Portfolio Management) then shows how to implement a portfolio view of your organization's business plan. Throughout the book, the authors presented enough real scenarios so I could find the lessons that directly applied to my challenges and ways to use Lean thinking to deal with them.
"Lean-Agile Software Development" is the best executive level review I've ever seen for getting more quality and productivity out of the folks developing our critical software tools. It also has insightful information for technical managers including Quality Assurance and Delivery Management.
3 of 7 found the following review helpful:
 Don't waste your money on this bookJun 03, 2010
By R. C. Rathore
Content of this book is incoherent. It was painful to read this book. Book is full of superficial guidelines, sound bites and meaningless diagrams. Look somewhere else if you want to gain knowledge on the subject to make improvements in your projects.
See all 8 customer reviews on Amazon.com
| | |
|
