Being Agile: Eleven Breakthrough Techniques to Keep You from "Waterfalling Backward" (Anglais) Broché – 21 octobre 2013
Rentrée scolaire 2017 : découvrez notre boutique de livres, fournitures, cartables, ordinateurs, vêtements ... Voir plus.
|Neuf à partir de||Occasion à partir de|
- Choisissez parmi 17 000 points de collecte en France
- Les membres du programme Amazon Prime bénéficient de livraison gratuites illimitées
- Trouvez votre point de collecte et ajoutez-le à votre carnet d’adresses
- Sélectionnez cette adresse lors de votre commande
Description du produit
Présentation de l'éditeur
Break the Old, Waterfall Habits that Hinder Agile Success:
Drive Rapid Value and Continuous Improvement
When agile teams don’t get immediate results, it’s tempting for them to fall back into old habits that make success even less likely. In Being Agile, Leslie Ekas and Scott Will present eleven powerful techniques for rapidly gaining substantial value from agile, making agile methods stick, and launching a “virtuous circle” of continuous improvement.
Drawing on their experience helping more than 100 teams transition to agile, the authors review its key principles, identify corresponding practices, and offer breakthrough approaches for implementing them. Using their techniques, you can break typical waterfall patterns and go beyond merely “doing agile” to actually thinking and being agile.
Ekas and Will help you clear away silos, improve stakeholder interaction, eliminate waste and waterfall-style inefficiencies, and lead the agile transition far more successfully. Each of their eleven principles can stand on its own: when you combine them, they become even more valuable.
- Building “whole teams” that cut across silos and work together throughout a product’s lifecycle
- Engaging product stakeholders earlier and far more effectively
- Overcoming inefficient “waterations” and “big batch” waterfall thinking
- Getting past the curse of multi-tasking
- Eliminating dangerous technical and project debt
- Repeatedly deploying “release-ready” software in real user environments
- Delivering what customers really need, not what you think they needn Fixing the root causes of problems so they don’t recur
- Learning from experience: mastering continuous improvement
- Assessing whether you’re just “doing agile” or actually “being agile”
Being Agile will be indispensable for all software professionals now adopting agile; for coaches, managers, engineers, and team members who want to get more value from it and for students discovering it for the first time.
Biographie de l'auteur
Scott Will has been with IBM for more than 22 years, the last six as an agile consultant. His experience ranges from providing consulting for small, co-located teams to teams with hundreds of engineers scattered across the world. Previously Scott was a successful programmer, tester, and customer support team lead, and he was in management for years. He is a contributing author to the book Agility and Discipline Made Easy, an IBM Master Inventor with numerous patents, a former Air Force combat pilot, and a graduate of Purdue University with a triple-major in Computer Science, Mathematics, and Numerical Analysis. He also completed his MBA while in the Air Force.
Aucun appareil Kindle n'est requis. Téléchargez l'une des applis Kindle gratuites et commencez à lire les livres Kindle sur votre smartphone, tablette ou ordinateur.
Pour obtenir l'appli gratuite, saisissez votre numéro de téléphone mobile.
Détails sur le produit
Si vous vendez ce produit, souhaitez-vous suggérer des mises à jour par l'intermédiaire du support vendeur ?
Commentaires client les plus utiles sur Amazon.com
The book is organized in a very consistent manner. Each chapter is a specific topic with a brief description of the topic, the guiding principles of Agile related to the topic, how to put it into practice, how to measure it and gather metrics, how to breakthrough and improve team performance and a summary of the chapter. All eleven topics addressed by the authors are areas where teams can improve. I found the material is straight-forward, concise and the recommendations for improvement are practical and easy to implement.
I especially like the Metrics and the Breakthrough sections in each chapter. The metrics provided simple examples of what to do & how to measure during the sprint. For example, the chapter on multi-tasking is excellent and a real eye-opener. In the metrics section, Scott Will discussed something we all have to deal with: how we manage our email inbox. I am taking his recommendations and implementing them into my daily work routine to improve how I spend my time. I have seen a noticeable time savings already in setting aside times during the day to just read email. Very helpful!
Thanks for this book and all the great ideas! I look forward to putting them into practice over the course of time.
After an introduction to the book and the perspective the authors have of agile practices, the book has a full chapter for each of the issues the authors have identified.
Chapter 1. Whole Teams
Chapter 2. Active Stakeholder Interaction
Chapter 3. Queuing Theory
Chapter 4. No Multitasking
Chapter 5. Eliminate Waste
Chapter 6. Working Software
Chapter 7. Deliver Value
Chapter 8. Release Often
Chapter 9. Stop the Line
Chapter 10. Agile Leadership
Chapter 11. Continuous Improvement
Every chapter has an introduction and then is broken down into 5 parts- Principles, Practices, Metrics, Breakthrough, and Summary.
The Principles section provides the theory, and the evidence for the practices that follow, for the topic at hand. The Metrics section provides suggestions on how you can measure how you are doing in the topic. The Breakthrough section gives recommendations on how to achieve a breakthrough in the troubled area. The summary provides a nice bullet point summary of the main points made throughout the chapter.
Every chapter in the book provides great advice, but when I turned to the first page of Chapter 4 and saw the title No Multitasking staring me back in the face I actually chuckled. Not because the authors went off track, but because I have yet to be in an environment where the management didn't believe the exact opposite. Most of the management teams were happy with your performance when you hit the threshold of having just enough multitasking going on that you are spread too thin to be effective in any of your tasks. To them context switching is just a myth. It doesn't really exist.
Chapter 6 has a section titled "Evolutionary Architecture and Emergent Design". Although there are a lot of books that miss the mark when describing these topics, I am glad these authors didn't. Unless a project is trivial, architecture cannot not be ignored, but the sad fact is, it is almost always overlooked. The problem is even though these books explain these topics correctly, if the readers don't have experience with architecture, it won't go any further than the explanations found in these books.
If they do have experience with architecture, and doing architecture right, they will already be doing architecture this way. Architecture is an activity as well as an iteratively developed asset which is both code and documentation. The number one quality attribute in almost all projects should be modifiability. If correct modifiability scenarios and tactics are applied early in the project, your architecture should easily absorb change.
The authors of the book say "Contrary to popular mythology, evolutionary architecture does start with an architectural model, just not a finished model. So, if you’ve heard that evolutionary architecture is nothing more than an architectural “wild-west show,” I ask you to set such thoughts aside and read on."
Chapter 9. Stop the Line is a great chapter. Stopping the line means that you stop what you are doing and fix a problem by fixing the root cause of the problem so that the problem does not return.
This concept is a hard sell no matter what the environment is. When there is a big show stopping issue, there is always a Band-Aid that is cheaper and faster than fixing the root of the problem, and when the business finds out they don't care anything about a root problem. Even if you know that over time the Band-Aid will cost them 5 times what fixing the root problem will, you better know how to communicate that in their language. This task takes usually takes an architect to actually pull it off.
I have witnessed CIOs, project managers, and developers fail at this repeatedly. The CIOs are not technically savvy enough to explain the issue or its future affects, the project managers are usually of the same mindset and looking for a quick fix to keep dates from slipping, and the developers are not used to having to present technical topics in a way the business understands.
Let's face it, there are way too many books, and way too much information available on agile these days. I'll be the first to admit, that every time I see an agile book coming out the first thing I think is how could they possibly still be milking agile. I also must admit, that many of the new books coming out on agile are now reflective of experience, and not based entirely on theory. That was what you used to find in the agile library, all theory and no experience.
Architecture, lifecycle phases, documentation, and specialized skill sets for certain roles throughout the process have made their way back into the agile world on projects that are larger than a 3 to 5 person team can handle. Thank goodness any good agile book you pick up today will either include these topics as absolutely essential, or you can throw it in the garbage.
I found the advice in this book to be dead on for the issues they discuss. The book is less than 300 pages, so it is a short read, full of practical and relevant advice, with absolutely no filler.
I highly recommend this book to those in the throes of trying to introduce agile practices into their environment.
The authors are not shy about sharing their extensive experience building enterprise software. I found myself nodding along on more to one occasion while reading the many anecdotes from the field sprinkled throughout.
The book is well-organized. Each chapter is devoted to one of eleven techniques, which in turn is divided into principles, practices metrics and breakthroughs expected. Of course the authors save the bet for last: Continuous Improvement, wich is rightly presented as the bedrock of the Agile methodology. The constant drive for individuals, teams and organizations to constantly improve on their past performance is the essence of successful software development (and more broadly, I would argue, of any human endevour).
This work is a great addition to the bookshelf of team members or leaders just starting out or well on their way in their Agile adventure.