Scaling Software Agility: Best Practices for Large Enterprises

If you're new to the agile process world, you may look at this book with a mixture of apprehension and skepticism. I would not blame you. Agile processes may seem the place of strange expressions--sprint, velocity, scrum (is this a rugby game?), extreme programming (are we jumping off cliffs with a snowboard?), user stories, epics and sagas (is this a writers' workshop?)--and weird social rituals--pair programming, user retrospectives, huddles or daily stand-up meetings (are developers and testers now hugging each other at work?). Agile teams also seem to consume inordinate amounts of colorful sticky notes and 4×6 index cards to cover any walls they can find, and the whole thing appears informal to a fault. We are in Dilbert-land. But make no mistake: agile software development processes are "crossing the chasm," to use the term coined by Jeffrey Moore, and we are today far beyond the funny, geeky jargon and into effective, productive, and scalable development methods.Agile projects are carefully planned, but they are planned differently, and the plan is revised and refined more often. You may also have been told that agile methods have their "sweet spots" around small teams (7 to 12 people), preferably collocated, for short projects (2 to 9 months), making them inapplicable in your own environment of large, long-lived, globally distributed software development endeavors. This too is all changing rapidly as numerous projects around the world are pushing these boundaries, and they are achieving success in higher productivity and higher quality of their software outcomes.Herein lays Dean's major contribution to be discovered in the body of this book. Rising above the debate between the various families of agile processes--XP, Scrum, Lean, DSDM, FDD, Rational Unified Process (RUP) and so on (which are nicely presented), he establishes what is common among them as a baseline before he proceeds to his main objective of showing how to scale these agile approaches beyond their existing sweet spot. He is not introducing a new agile process to add to this already long roster, but rather he extends them all with a set of new practices, practices that live at a higher level, both technical and managerial, and that embrace and integrate existing established agile practices (the ones with the funny names). In addition to synthesizing the best engineering practices that are common among these methods, he also describe methods aiming at the governance of larger agile projects: topics such as release planning; handling large, distributed teams; establishing the business value of the project; and dealing with large, long-lived developments, to mention only a few.The author's work is not academic, he's not merely positing some new bold conjectures for you to try out. His advice is rooted in years of active, hands-on practice in many companies, many projects, in a wide range of industries, from life-sustaining medical equipment to software tools, from amusement park rides to large-scale IT infrastructure applications.Philippe KruchtenVancouver, BC CanadaPS:Yes, I am the same guy who wrote the foreword. I have not changed my mind since. The Rational Unified Process: An Introduction, Third Edition The Rational Unified Process Made Easy: A Practitioner's Guide to Rational Unified Process Software Engineering Processes: With the UPEDU

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.

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.

This is a must read for those serious about scaling Agile. The author discusses the challenges of scaling, the drawbacks of existing processes and the limitations in Agile itself and builds on top to address those issues providing practical lessons on applying agile methods at scale.It would have been great if the author were to include more stories and more examples to make it a better read. However, the ample number of lessons and advice make up for that.

Ok, if you are new to agile than i would say this is a very good book (4 stars). It gives a good overview of scrum and other methods in an easy to understand and very pedagogical writing. The parts covering RUP and how this could be used in an agile way was quite interesting.However, the title talks about scaling and large enterprise so my expectation was not an agile introduction but i was expecting a book focusing on scaling (sure, introduction is ok, but in this case 2/3 of the book is introduction).The scaling parts are ok, but on a very high level. There are some challenges described (like architecture, co-location etc) but i feel it miss a lot when it comes to solutions. Sure, there is not one true way to mitigate the challenges, but these areas is where i expected more focus.In summary, an OK book, but if you already have experience in agile you will not learn a lot more.

Un buon libro con anche indicazioni pratiche e operative ed una introduzione ai concetti e principali metodologie agile. In inglese ma con stile molto fluido. Si legge senza difficoltà.

Je l'ai utilisé dans le cadre d'une transformation au sein de mon entreprise, tout y est l'essentiel et le must have.