Scaling Software Agility
and over one million other books are available for Amazon Kindle .
Learn more
| |||||||||||||||
 Trade In this Item for up to £12.00
Get an extra £5 when you trade in books worth £10 or more until June 30, 2012. Trade in Scaling Software Agility: Best Practices for Large Enterprises (Agile Software Development) for an Amazon.co.uk gift card of up to £12.00, which you can then spend on millions of items across the site. Trade-in values may vary (terms apply). Find more products eligible for trade-in.
|
Frequently Bought Together
Product details
|
More About the Author
Product Description
Product Description
“Companies have been implementing large agile projects for a number of years, but the ‘stigma’ of ‘agile only works for small projects’ continues to be a frequent barrier for newcomers and a rallying cry for agile critics. What has been missing from the agile literature is a solid, practical book on the specifics of developing large projects in an agile way. Dean Leffingwell’s book Scaling Software Agility fills this gap admirably. It offers a practical guide to large project issues such as architecture, requirements development, multi-level release planning, and team organization. Leffingwell’s book is a necessary guide for large projects and large organizations making the transition to agile development.”
–Jim Highsmith, director, Agile Practice, Cutter Consortium, author of Agile Project Management“There’s tension between building software fast and delivering software that lasts, between being ultra-responsive to changes in the market and maintaining a degree of stability. In his latest work, Scaling Software Agility, Dean Leffingwell shows how to achieve a pragmatic balance among these forces. Leffingwell’s observations of the problem, his advice on the solution, and his description of the resulting best practices come from experience: he’s been there, done that, and has seen what’s worked.”
–Grady Booch, IBM Fellow
Preface
Acknowledgments
About the Author
Part I: Overview of Software Agility
Chapter 1: Introduction to Agile Methods
Chapter 2: Why the Waterfall Model Doesn’t Work
Chapter 3: The Essence of XP
Chapter 4: The Essence of Scrum
Chapter 5: The Essence of RUP
Chapter 6: Lean Software, DSDM, and FDD
Chapter 7: The Essence of Agile
Chapter 8: The Challenge of Scaling Agile
Part II: Seven Agile Team Practices That Scale
Chapter 9: The Define/Build/Test Component Team
Chapter 10: Two Levels of Planning and Tracking
Chapter 11: Mastering the Iteration
Chapter 12: Smaller, More Frequent Releases
Chapter 13: Concurrent Testing
Chapter 14: Continuous Integration
Chapter 15: Regular Reflection and Adaptation
Part III: Creating the Agile Enterprise
Chapter 16: Intentional Architecture
Chapter 17: Lean Requirements at Scale: Vision, Roadmap, and Just-in-Time Elaboration
Chapter 18: Systems of Systems and the Agile Release Train
Chapter 19: Managing Highly Distributed Development
Chapter 20: Impact on Customers and Operations
Chapter 21: Changing the Organization
Chapter 22: Measuring Business Performance
Conclusion: Agility Works at Scale
Bibliography
Index
–Jim Highsmith, director, Agile Practice, Cutter Consortium, author of Agile Project Management“There’s tension between building software fast and delivering software that lasts, between being ultra-responsive to changes in the market and maintaining a degree of stability. In his latest work, Scaling Software Agility, Dean Leffingwell shows how to achieve a pragmatic balance among these forces. Leffingwell’s observations of the problem, his advice on the solution, and his description of the resulting best practices come from experience: he’s been there, done that, and has seen what’s worked.”
–Grady Booch, IBM Fellow
Agile development practices, while still controversial in some circles, offer undeniable benefits: faster time to market, better responsiveness to changing customer requirements, and higher quality. However, agile practices have been defined and recommended primarily to small teams. In Scaling Software Agility, Dean Leffingwell describes how agile methods can be applied to enterprise-class development.
- Part I provides an overview of the most common and effective agile methods.
- Part II describes seven best practices of agility that natively scale to the enterprise level.
- Part III describes an additional set of seven organizational capabilities that companies can master to achieve the full benefits of software agility on an enterprise scale.
This book is invaluable to software developers, testers and QA personnel, managers and team leads, as well as to executives of software organizations whose objective is to increase the quality and productivity of the software development process but who are faced with all the challenges of developing software on an enterprise scale.
Preface
Acknowledgments
About the Author
Part I: Overview of Software Agility
Chapter 1: Introduction to Agile Methods
Chapter 2: Why the Waterfall Model Doesn’t Work
Chapter 3: The Essence of XP
Chapter 4: The Essence of Scrum
Chapter 5: The Essence of RUP
Chapter 6: Lean Software, DSDM, and FDD
Chapter 7: The Essence of Agile
Chapter 8: The Challenge of Scaling Agile
Part II: Seven Agile Team Practices That Scale
Chapter 9: The Define/Build/Test Component Team
Chapter 10: Two Levels of Planning and Tracking
Chapter 11: Mastering the Iteration
Chapter 12: Smaller, More Frequent Releases
Chapter 13: Concurrent Testing
Chapter 14: Continuous Integration
Chapter 15: Regular Reflection and Adaptation
Part III: Creating the Agile Enterprise
Chapter 16: Intentional Architecture
Chapter 17: Lean Requirements at Scale: Vision, Roadmap, and Just-in-Time Elaboration
Chapter 18: Systems of Systems and the Agile Release Train
Chapter 19: Managing Highly Distributed Development
Chapter 20: Impact on Customers and Operations
Chapter 21: Changing the Organization
Chapter 22: Measuring Business Performance
Conclusion: Agility Works at Scale
Bibliography
Index
From the Back Cover
“Companies have been implementing large agile projects for a number of years, but the ‘stigma’ of ‘agile only works for small projects’ continues to be a frequent barrier for newcomers and a rallying cry for agile critics. What has been missing from the agile literature is a solid, practical book on the specifics of developing large projects in an agile way. Dean Leffingwell’s book Scaling Software Agility fills this gap admirably. It offers a practical guide to large project issues such as architecture, requirements development, multi-level release planning, and team organization. Leffingwell’s book is a necessary guide for large projects and large organizations making the transition to agile development.”
–Jim Highsmith, director, Agile Practice, Cutter Consortium, author of Agile Project Management“There’s tension between building software fast and delivering software that lasts, between being ultra-responsive to changes in the market and maintaining a degree of stability. In his latest work, Scaling Software Agility, Dean Leffingwell shows how to achieve a pragmatic balance among these forces. Leffingwell’s observations of the problem, his advice on the solution, and his description of the resulting best practices come from experience: he’s been there, done that, and has seen what’s worked.”
–Grady Booch, IBM Fellow
Preface
Acknowledgments
About the Author
Part I: Overview of Software Agility
Chapter 1: Introduction to Agile Methods
Chapter 2: Why the Waterfall Model Doesn’t Work
Chapter 3: The Essence of XP
Chapter 4: The Essence of Scrum
Chapter 5: The Essence of RUP
Chapter 6: Lean Software, DSDM, and FDD
Chapter 7: The Essence of Agile
Chapter 8: The Challenge of Scaling Agile
Part II: Seven Agile Team Practices That Scale
Chapter 9: The Define/Build/Test Component Team
Chapter 10: Two Levels of Planning and Tracking
Chapter 11: Mastering the Iteration
Chapter 12: Smaller, More Frequent Releases
Chapter 13: Concurrent Testing
Chapter 14: Continuous Integration
Chapter 15: Regular Reflection and Adaptation
Part III: Creating the Agile Enterprise
Chapter 16: Intentional Architecture
Chapter 17: Lean Requirements at Scale: Vision, Roadmap, and Just-in-Time Elaboration
Chapter 18: Systems of Systems and the Agile Release Train
Chapter 19: Managing Highly Distributed Development
Chapter 20: Impact on Customers and Operations
Chapter 21: Changing the Organization
Chapter 22: Measuring Business Performance
Conclusion: Agility Works at Scale
Bibliography
Index
–Jim Highsmith, director, Agile Practice, Cutter Consortium, author of Agile Project Management“There’s tension between building software fast and delivering software that lasts, between being ultra-responsive to changes in the market and maintaining a degree of stability. In his latest work, Scaling Software Agility, Dean Leffingwell shows how to achieve a pragmatic balance among these forces. Leffingwell’s observations of the problem, his advice on the solution, and his description of the resulting best practices come from experience: he’s been there, done that, and has seen what’s worked.”
–Grady Booch, IBM Fellow
Agile development practices, while still controversial in some circles, offer undeniable benefits: faster time to market, better responsiveness to changing customer requirements, and higher quality. However, agile practices have been defined and recommended primarily to small teams. In Scaling Software Agility, Dean Leffingwell describes how agile methods can be applied to enterprise-class development.
- Part I provides an overview of the most common and effective agile methods.
- Part II describes seven best practices of agility that natively scale to the enterprise level.
- Part III describes an additional set of seven organizational capabilities that companies can master to achieve the full benefits of software agility on an enterprise scale.
This book is invaluable to software developers, testers and QA personnel, managers and team leads, as well as to executives of software organizations whose objective is to increase the quality and productivity of the software development process but who are faced with all the challenges of developing software on an enterprise scale.
Preface
Acknowledgments
About the Author
Part I: Overview of Software Agility
Chapter 1: Introduction to Agile Methods
Chapter 2: Why the Waterfall Model Doesn’t Work
Chapter 3: The Essence of XP
Chapter 4: The Essence of Scrum
Chapter 5: The Essence of RUP
Chapter 6: Lean Software, DSDM, and FDD
Chapter 7: The Essence of Agile
Chapter 8: The Challenge of Scaling Agile
Part II: Seven Agile Team Practices That Scale
Chapter 9: The Define/Build/Test Component Team
Chapter 10: Two Levels of Planning and Tracking
Chapter 11: Mastering the Iteration
Chapter 12: Smaller, More Frequent Releases
Chapter 13: Concurrent Testing
Chapter 14: Continuous Integration
Chapter 15: Regular Reflection and Adaptation
Part III: Creating the Agile Enterprise
Chapter 16: Intentional Architecture
Chapter 17: Lean Requirements at Scale: Vision, Roadmap, and Just-in-Time Elaboration
Chapter 18: Systems of Systems and the Agile Release Train
Chapter 19: Managing Highly Distributed Development
Chapter 20: Impact on Customers and Operations
Chapter 21: Changing the Organization
Chapter 22: Measuring Business Performance
Conclusion: Agility Works at Scale
Bibliography
Index
Inside This Book
(Learn More)
Suggested Tags from Similar Products(What's this?)Be the first one to add a relevant tag (keyword that's strongly related to this product)
|
What Other Items Do Customers Buy After Viewing This Item?
Customer Reviews
Most Helpful Customer Reviews
1 of 1 people found the following review helpful
Format:Paperback
I have a vast collection of books on Agile methods. All of them, apart from this book, leave a gap concerning how to deal with projects where deep analysis is required and yet the project still be Agile. These are the sorts of problems that Enterprise's deal with and are a million miles away from typical web-based applications, which I tend to see as broad but shallow, supporting what is unkindly called "whim-driven" requirements. This book addresses the full range of projects and shows how to preserve the benefits of Agile in large-scale, in-depth projects. The style is readable with a refreshing lack of agile dogma, replaced by attention to principles rather than rules. By doing this it provides scalable solutions. Use Cases make an appearance in the book, with the qualification that they are needed when more analysis is requried,. Exactly! User Stories, to me at least, seem to reflect the "divide and conquer" approach as well as "need to know" and "not seeing the wood for the trees". Refactoring is a great and well known concept. It is not so great if it causes the architecture to be refactored and issues such as this are well discussed in the book. The book applies a needed pinch of salt to Agile as a Religion. If you are looking for an Agile Cookbook, this is not it. If you want a book to help you understand how to get the best of Agile in more complex environments, buy it.
Most Helpful Customer Reviews on Amazon.com (beta)
Amazon.com:
27 reviews
31 of 32 people found the following review helpful
Good introduction but missing some of the hard parts
3 May 2007
Format:Paperback|Amazon Verified Purchase
I've long been switching between 3 or 4 stars rating for this book. So let me start by saying that my 3 starts means that the book is really worth reading, however some parts of the book do not go deep enough, in my opinion.
Scaling Software Agility tackles the question "How to do agile development in large systems". The experience in the book seems to mainly be build on one project in BMC. In the first part of the book, Dean goes over the most popular agile methods and gived a quick introduction. He then attempts to extract common parts for the methods. In part two he picks out 7 practices and claims that they scale without modification. In the last part of the book, he adds 7 new practices, which, in his opinion, are needed for large agile projects.
Personally I've been working with a lot of large agile projects and thus was very interested in this book, especially to learn new things or see if Dean had similar problems. I was slightly dissapointed, but let me explain.
One of the fundamental points in the book is that agile development can be executed on team level. The unit of work is what Dean calls "component teams". In his book, he does not cover the question of code ownership, but the component team organization suggests a traditional organization based on the architecture of the system. This is confirmed by the problems he mentions, which are inherent to component teams. These are the need for more architecture, the need for much dependency management between the component teams and several others. Dean keeps with the traditional methods of organizing projects, he doesn't question it. The component teams thus lose part of the end-customer focus and more management and architecture is needed. Slowly parts of waterfall development are re-emerging. The book does NOT cover the organization around feature teams and the scaling of practices like shared code ownership. Also it doesn't talk about continuous integration in relationship to the team structure etc. A missed opportunity.
In part two, Dean describes 7 practices which scale without adjustment. I totally agree that these practices scale, but there is some need for doing them slightly different. As example, "how do we coordinate the different planning meetings?" The book explains the traditional practice but does NOT talk about how to actually scale it. It doesn't mention different problems that might happen and different possible solutions. It seems to just cover the surface of the subject.
The last chapters about how agile development will influence the rest of the organization were good. They touch a subject that is currently rarely covered.
In conclusion, a useful book to read. I would not follow all recommendations and more needs to be written on the subject. Still, definitively worth reading.
Scaling Software Agility tackles the question "How to do agile development in large systems". The experience in the book seems to mainly be build on one project in BMC. In the first part of the book, Dean goes over the most popular agile methods and gived a quick introduction. He then attempts to extract common parts for the methods. In part two he picks out 7 practices and claims that they scale without modification. In the last part of the book, he adds 7 new practices, which, in his opinion, are needed for large agile projects.
Personally I've been working with a lot of large agile projects and thus was very interested in this book, especially to learn new things or see if Dean had similar problems. I was slightly dissapointed, but let me explain.
One of the fundamental points in the book is that agile development can be executed on team level. The unit of work is what Dean calls "component teams". In his book, he does not cover the question of code ownership, but the component team organization suggests a traditional organization based on the architecture of the system. This is confirmed by the problems he mentions, which are inherent to component teams. These are the need for more architecture, the need for much dependency management between the component teams and several others. Dean keeps with the traditional methods of organizing projects, he doesn't question it. The component teams thus lose part of the end-customer focus and more management and architecture is needed. Slowly parts of waterfall development are re-emerging. The book does NOT cover the organization around feature teams and the scaling of practices like shared code ownership. Also it doesn't talk about continuous integration in relationship to the team structure etc. A missed opportunity.
In part two, Dean describes 7 practices which scale without adjustment. I totally agree that these practices scale, but there is some need for doing them slightly different. As example, "how do we coordinate the different planning meetings?" The book explains the traditional practice but does NOT talk about how to actually scale it. It doesn't mention different problems that might happen and different possible solutions. It seems to just cover the surface of the subject.
The last chapters about how agile development will influence the rest of the organization were good. They touch a subject that is currently rarely covered.
In conclusion, a useful book to read. I would not follow all recommendations and more needs to be written on the subject. Still, definitively worth reading.
14 of 14 people found the following review helpful
No insights into how toscale Agile
16 Dec 2007
Format:Paperback
If you are looking into insights to scaling Agile projects you will be dissapointed.
The auther largly discribes the outlines of different development methodologies in the book, Xp, Scrum, DSDM, RUP. It takes to page 87 before the actual content of the book (scaling) even begins.
But when push comes to shove, the authors silently reverts to the basic monotholic arcitecture message "agile is good in small teams, but shall not be trusted in large environments". That is saying "I have no new insights into managing the impediments of large organisation".
What I was expecting was some new insights into of breaking down communication and cultural barriers that are in the way of scaling Agile projects, lean software techologies in the large etc.
At is best, the book provides a good compilation of development methologies, at it's worst, it mixes up the cards so bad that you will end up even more confused than before you started.
If you are looking into scaling agile, "The Enterprices and scrum" and any of Jeff Sutherlands scrum-of-scrum papers are a better bet.
The auther largly discribes the outlines of different development methodologies in the book, Xp, Scrum, DSDM, RUP. It takes to page 87 before the actual content of the book (scaling) even begins.
But when push comes to shove, the authors silently reverts to the basic monotholic arcitecture message "agile is good in small teams, but shall not be trusted in large environments". That is saying "I have no new insights into managing the impediments of large organisation".
What I was expecting was some new insights into of breaking down communication and cultural barriers that are in the way of scaling Agile projects, lean software techologies in the large etc.
At is best, the book provides a good compilation of development methologies, at it's worst, it mixes up the cards so bad that you will end up even more confused than before you started.
If you are looking into scaling agile, "The Enterprices and scrum" and any of Jeff Sutherlands scrum-of-scrum papers are a better bet.
3 of 3 people found the following review helpful
Don't recommend it if you've had intermediate exposure to agile
29 Nov 2010
Format:Paperback
I've had some exposure to agile methods - I'd consider myself leaning heavily towards the XP camp. A bit of Scrum.
This book is no Embrace Change or one of the Poppendieck Lean books. The title promises more than the book can deliver.. For me the book didn't get into the trenches with the various suggestions for scaling.
Scaling agile is a tough job.. In my experience there aren't enough good POs, devs, SMs to go around in a typical organization. The book doesn't even address this important point - the skills gap to bridge the chasm from the Tayloristic organization to empowered self org teams. I've found this to be a big hurdle.
The first section is an overview of the different flavors like XP, Scrum, RUP, etc.. more nice to know than useful.
The new bits were
- the Release Train (which is synchronized teams with predefined milestones w.r.t. content delivery and dates
- Component teams (there are some challenges here when there are multiple client teams for a component team. A strong PO is a must. Otherwise it just descends into chaos and finger pointing.)
- the architecture runway (Once again, it depends on who is sitting in the ivory tower. The flipside, is the architecture "runaway", where the Component teams are just unquestioningly following the pied architect of hamelin.)
Summary:
I don't feel any more confident that I was before I read the book. Not a lot has changed...
- Agile is hard work... Inspect and adapt.
- You need a balance between upfront design (minimal) and emergent design.
- Estimation and Planning needs to be empirical, mathematics doesn't work. Never did.
- Mastering the iteration aka Execution. To scale, the smallest units need to be good at execution. That needs craftsmen, that are hard to find and keep.
- the requirements problem is still hard. You need to have a conversation with the end user and eliminate any middlemen.
2 stars since I was handed down this book. If I had paid for it, it would be lower. Disclaimer: I've read a bunch of books on agile before this, maybe to someone who is testing the waters, it would be more beneficial. But then again, maybe they should be reading the core texts well before embarking on scaling it up.
This book is no Embrace Change or one of the Poppendieck Lean books. The title promises more than the book can deliver.. For me the book didn't get into the trenches with the various suggestions for scaling.
Scaling agile is a tough job.. In my experience there aren't enough good POs, devs, SMs to go around in a typical organization. The book doesn't even address this important point - the skills gap to bridge the chasm from the Tayloristic organization to empowered self org teams. I've found this to be a big hurdle.
The first section is an overview of the different flavors like XP, Scrum, RUP, etc.. more nice to know than useful.
The new bits were
- the Release Train (which is synchronized teams with predefined milestones w.r.t. content delivery and dates
- Component teams (there are some challenges here when there are multiple client teams for a component team. A strong PO is a must. Otherwise it just descends into chaos and finger pointing.)
- the architecture runway (Once again, it depends on who is sitting in the ivory tower. The flipside, is the architecture "runaway", where the Component teams are just unquestioningly following the pied architect of hamelin.)
Summary:
I don't feel any more confident that I was before I read the book. Not a lot has changed...
- Agile is hard work... Inspect and adapt.
- You need a balance between upfront design (minimal) and emergent design.
- Estimation and Planning needs to be empirical, mathematics doesn't work. Never did.
- Mastering the iteration aka Execution. To scale, the smallest units need to be good at execution. That needs craftsmen, that are hard to find and keep.
- the requirements problem is still hard. You need to have a conversation with the end user and eliminate any middlemen.
2 stars since I was handed down this book. If I had paid for it, it would be lower. Disclaimer: I've read a bunch of books on agile before this, maybe to someone who is testing the waters, it would be more beneficial. But then again, maybe they should be reading the core texts well before embarking on scaling it up.
Were these reviews helpful?
Let us know
Listmania!
|
|
Look for similar items by category
- Books > Business, Finance & Law > Careers > Entrepreneurship
- Books > Business, Finance & Law > Management
- Books > Business, Finance & Law > Small Business & Entrepreneurship > Entrepreneurship
- Books > Computing & Internet > Digital Lifestyle > Online Shopping > Amazon
- Books > Computing & Internet > Programming > Software Design, Testing & Engineering > Agile Programming
Look for similar items by subject
Feedback
- Would you like to update product info or give feedback on images?
- I am the Author, and I want to comment on my book.
- I am the Publisher, and I want to comment on this book.
|
