Enterprise-Scale Agile Software Development
Enterprise-Scale Agile Software Development is the collective sum of knowledge accumulated during the full-scale transition of a 1400-person organization to agile development—considered the largest implementation of agile development and Scrum ever attempted anywhere in the world.
Now James Schiel, a certified Scrum trainer and member of the Scrum Alliance, draws from his experience at the helm of that global four-year project to guide you and your organization through the transition. He lends his insight on how you can use Scrum as an organizational framework and implement XP practices to define how software is written and tested. He provides key information and tools to assess potential outcomes and then make the best corresponding choices in any given situation.
Schiel sequences chapters to match typical developmental progression, and in addition to practical guidance, he provides a tool kit from which you can take ideas and select what works for you. Covering quality development practices based on ISO 9001, which help you create consistently high-quality software in a cost-efficient manner, this invaluable resource shows you how to:
- Improve project management practices and product quality assurance
- Adopt new management methods and requirements
- Involve your current customers in development, while inviting new ones
Much more than a mere "body of knowledge," this volume goes beyond standardizing agile and Scrum practices. It breaks up the process into manageable tasks, illustrating how to set the stage for the change, plan it, and then initiate it. Using the methods and information presented, any organization should be able to achieve a nearly seamless transition to agile.
Review By: Mark Cole
10/13/2010This book explains how the agile process works and lays out the steps for those looking to transition to agile. Anyone who is transitioning to Scrum should know the contents of this book in some way or another. So "Why Scrum?" (That question is the title of the second chapter.) One thing I kept thinking about when I read this book is the power of working as a collaborative team. This team works to get a single task done in the time limit established by the sprint (three to six weeks).
The Scrum methodology applies this method to an individual and a team. In daily scrum meetings, the team answers the following three questions: "What did I do yesterday?" "What I am going to do today?" "Are there any impediments?"
Working as a team on a common goal and speaking a common language sounds great, but doing so creates a paradigm shift for a lot of us. It is also true that there are a lot of developers out there who are very focused on solving problems and not very focused on working with others.
After laying out the foundation for why you should transition from old development practices to agile development, Schiel gives step-by-step instructions on how execute this transition on an enterprise scale. The plan is excellently done, fairly concisely, and practical. Schiel discusses all the things that might get in the way in chapter 4, "Transition Barriers," in which he splits these obstacles into people and organizational barriers. He talks about hiring new team members and how to improve scrum team performance. He also talks about how to "Create the Transition Team" (chapter 6), and uses the transition process itself as a place to start your first sprint.
Some of my minor complaints about this book would be that it is too focused on management. I would like to know more about how a software tester, a business analyst, or a software developer can or needs to maximize their productivity using the Scrum. Sometimes it seems like all the training is focused on management. People in other roles are dumped into the middle of a sprint with little information on the transition they are making. In other words, I would like chapters that are role specific. My other minor complaint is that Schiel talks about how he led a "successful implementation in an organization with 1400 developers and managers working in several development sites spread around the world." Well, how did that all turn out? Did they make a ton of money? What was the employee turnover? Did everyone agree (customers, developers, etc.) that the effort was successful? I would have enjoyed an epilogue where he shows me how the step-by-step totally worked out in practice and how the difficult transition resulted in an increase of profits and happiness.
Over all reading this book was an eye-opening experience to me on the power of teamwork. This book is a classic in the software engineering field.
Review By: Matt Gelbwaks
10/13/2010"On the day that I began what eventually became a full-scale transition of a fourteen-hundred-person organization to agile development, I had absolutely no idea what I was getting myself into," writes author James Schiel. This opening sentence calls out to those folks who've found themselves in a similar position. Unfortunately, Mr. Schiel says that none of us ever recognize when we are in that moment until it has passed and we have the gracious benefit of hindsight. So it could be said that this book is really for those who might suspect that they may be part of a larger transformation.
Mr. Schiel’s book helps the reader understand much of why certain things are done during a transformation that he might be part of. This book provides much of the explanation and expectation within the terms of fair process that will help you, your teams, and your organization understand why you are being asked to change your behaviors (and tacitly, your performance).
The points the author makes that I particularly like is that teamwork is necessary for change and that any individual’s technical skills are only partly sufficient. In other words, no matter how great an individual contributor you are, if you can't work as part of the larger team, you will probably be marked as dispensable. Not a cozy thought in a transformational period. I also am thrilled to see more folks than just me suggest we trend management back towards matrix and away from purely functional. It is refreshing and, dare I say, transformational!
The problem with writing a definitive book is that it’s hard to be definitive when the future is uncertain. The mere suggestion that people should read James Schiel’s book will hopefully change the possible future of a generation. Now, at least some folks in every agile transformation will know what to expect (at least in broad terms), and hopefully many transformation leaders will know more of those points that need explanation and thus will then know more on how to set expectations.
This book stands out as a guide to practical application of Scrum and agile methods. There is no other step-by-step guide to implementing agile within a project, nevertheless an entire organization. Though I do not agree with every point he makes, I can't argue that these are all fine first steps to make towards an inclusive transformation.
The only additional point I would ask readers to remember is that they need to be retrospective in the process as well as their projects. If you start with the agile adoption recipe in this book, thoroughly taste the first agile cake that comes out of the oven before baking another one. Experience gained when baking the first cake will become your best teacher for the second cake.