Customer Reviews

Scaling Software Agility: Best Practices for Large Enterprises

5 star:		(16)
4 star:		(8)
3 star:		(1)
2 star:		(2)
1 star:		(0)

 

 

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.

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.

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.

As someone who has guided many enterprise organizations in scaling Scrum, this book covers all of the critical roadblocks that are sure to be in your path. Scaling Software Agility is a must read for anyone in a technical or business leadership capacity considering advancing agile beyond a few teams or projects. It combines the organizational influences from Scrum with the development practices of Extreme Programming (XP) and balances it with some of the best practices from the Rational Unified Process (RUP) to provide a scalable agile approach.

Dean Leffingwell eases you into scaling agile in a very comfortable way - first through reviewing many of the existing methods, then through showing how many of the common practices you are implementing today actually scale, and finally through recognizing the key differences and approaches required in scaling agile to a large enterprise. His many years experience in agile (and more importantly non-agile) environments come through in the way he walks you through his discovery of this scalable agile approach.

Dean also doesn't hold back any punches in his critique of agile practices and what is needed, or needs to be changed, to scale them. He is quite direct in his opposition to XP's emergent architectural approach and its inability to scale - rather he introduces Intentional Architecture. Is it too prescriptive to be agile? If you are an enterprise architecture developing systems of systems, you might not think so. Dean provides some excellent ideas to help balance architectural discovery and planning to keep your runway long and clear.

Dean is perhaps best known for his work in Requirements Management. In this book he visits each of the agile, iterative and lean requirements approaches to explain how a balanced, just-in-time approach provides the right mix to scale. I find that this is often the biggest change to most enterprise organizations that tend to write verbose specifications and have the most concerns about project scope and governance. Dean provides a clear picture of how to manage requirements efficiently.

While each of the chapters in the later half of this book could fill an entire book itself, Dean does an excellent job in presenting the critical elements of each and just enough to help get you going down the right path. Yet I would have preferred to see more depth in organizational structures which influence agile scalability - an area that I find particularly troublesome for most large companies. However, as Dean said in describing his book, "If this book were any thicker, it wouldn't be agile."

As a co-founder of a small start-up company that grew to 160 people, survived the internet bubble / burst and ultimately was acquired, I never truly understood why large software companies continuously fail to convert themselves to more agile driven organizations.

That is until immediately after our acquisition. For the past year, my team and I have successfully convinced many crucial business owners throughout the organization that agile driven concepts as described by Dean Leffingwell are crucial to delivering better software faster.

Unfortunately, even though we have made tremendous progress in several key areas, we have been unsuccessful in truly influencing other organizations throughout the company. The past year has been an extremely frustrating experience in many aspects. Furthermore, no matter how hard I tried to learn and research proven methods, I rarely found extensive material to help us on our journey.

For the first time, a book accomplished the missing void we saught so hard to find. Dean's book truly hits the mark and accurately describes why so many companies have such a hard time converting. He provides history behind the agile methodologies in order to provide proper context. The history lesson is informative even for individuals who have a strong background. He completes the book by breaking out agile concepts that scale regardless of size and more importantly, he also covers several concepts that if implemented, help a large company adapt to more agile best practices.

My only knock on the book is that I wish he would have spent more time on the one key issue that continues to kill us - the need for organizational change. However, after thinking about this issue for a while, what can an author really do to improve a company's ability to change the organizational structure? Not much I am afraid...

This is a fantastic book that everyone should read - even folks that work in small companies. I am confident that the reader will walk away with at least a few good ideas to leverage now or as the company grows. If you already work at a large company, the book will at a minimum give you some peace of mind and hopefully will serve as a vehicle to encourage change by others.

Thanks for an outstanding book!

Dean has done a excellent job and this book is a MUST have for any large organization moving to Agile. It sure helped this old dog put the enterprise pieces of the puzzle together.

Sr. Enterprise Business Analyst

Agile practices are here to stay, and they are making rapid inroads in small and large companies. Most companies with whom I work, struggle with how to make agile scale. How do you make agile practices integrate within the existing governance structure of large organizations? Do we need to modify the agile cook book answer to capturing and managing requirements, to architecture, and how to structure teams as we make agile scale? I find that Dean does an excellent job answering these types of questions.

Most companies seek to leverage a hybrid approach (as noted by survey's by Dr. Dobbs and Forrester), where they integrate agile practices, with practices that are known to work but may not normally be considered agile. But which agile practices will work well in large scale environments? Which needs to be tuned? Are there any practices preceding agile that may be worth keeping? Do these practices need to be tuned to align with lean and agile thinking?

Dean takes a very pragmatic approach to this problem, describing what works for him and the companies with whom he has worked. Let's have a quick look at each of the 3 parts:

Part 1. For those less familiar with agile, he provides a foundation including an overview of key agile, lean, and iterative processes. He provides an insightful description of strengths and weaknesses of XP, Scrum, RUP, etc. I find the sections easy to read, and I appreciate that he dares to step away from the sometimes tiring agile rhetoric.

Part 2. He describes what he sees as 7 core agile practices that work for teams of any size. For people well acquainted with agile, there should be no big surprises here. Most people would agree with the practices he describes, even though every author has their own way of slicing and dicing these core practices. Dean does however do a very nice job getting to the core of these practices.

Part 3. In section 3, Dean describes 7 practices that help you create the agile enterprise. This is the section where it gets the most interesting. Not everybody will agree with everything here, but I think everybody will find interesting viewpoints from which they can learn from. I especially like the discussions on "Intentional Architecture" respectively "Systems of Systems and the Agile Release Train". If Dean does another revision of the book, I would recommend adding suggestions on more specific metrics on the chapter on metrics, since this is an area in which many companies are struggling.

Overall, I found the book to be clear and quite compelling. I would strongly recommend it for anybody that would like to make agile scale within a company.

4-/5

I bought the book because I heard Dean Leffingwell speak about "A Lean and Scalable Requirements Information Model for the Agile Enterprise" (although I think the talk was more in line with his new book Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise).

Anyway I think this a good title to read when you've come some way down the Agile road and are wondering how all this is supposed to fit into a larger product development organization. The book won't give all the answers for those actually struggling to scale Agile development in their work but is still a valuable tool and a good "the next book" after titles like Agile and Iterative Development: A Manager's Guide and Agile Estimating and Planning. It should not be your first Agile book though!

Mr. Leffingwell is a good writer and his style makes you feel like you are really making progress with the book. Even his previous book about software requirements felt like a quick read while being quite lengthy with 544 pages. I consider this quite an accomplishment for a writer (in this industry) and it is something other authors in the field should try to reach for.

Dean have made a fantastic book, it gives a very good description of topics in scaling Agile in large enterprises. I would highly recommend it to others, not as the first book you read on Agile and Scrum, but certainly a fantastic follow-up when you understand the basic.

Dean Leffingwell adds important ideas to the application of Agile on multi-team distributed projects. Successful large SW Project Management is difficult enough and doing so with varied teams using a variety of processes can lead to solutions where the pieces and parts work but the whole doesn't work together. This book has useful techniques for addressing that and should be read by anyone leading a large SW project or an Agile team contributing to a large project. One minor criticism is the book does spend a fair amount of time on a survey of existing team level practices, which are readily available online, when the space might have been better used to address more large multi-team project examples.