Being Agile: Eleven Breakthrough Techniques to Keep You from "Waterfalling Backward" 1st Edition, Kindle Edition
|New from||Used from|
|Length: 218 pages||Enhanced Typesetting: Enabled||Page Flip: Enabled|
Kindle e-ReadersFire TabletsFire Phones
Enter your mobile number or email address below and we'll send you a link to download the free Kindle App. Then you can start reading Kindle books on your smartphone, tablet, or computer - no Kindle device required.
To get the free app, enter your mobile phone number.
About the Author
Leslie Ekas has worked in software development for over 20 years as a developer, manager, and agile coach. Her industry experience ranges from a startup, to a mid-sized company, and now IBM. She has led multiple products to market successfully over the years. She has managed teams of all sizes and many disciplines and across broad geographies. Leslie helped start the IBM Software Group Agile Center of Competence after her team’s early success transforming to agile. After coaching for several years, she returned to development to lead the worldwide Rational ClearCase team. In her new job as the Smarter Infrastructure Portfolio Manager, she is helping the business team adopt an agile operational approach.
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.--This text refers to an out of print or unavailable edition of this title.
- Publication date : October 15, 2013
- File size : 5015 KB
- Word Wise : Not Enabled
- Print length : 218 pages
- X-Ray : Not Enabled
- Enhanced typesetting : Enabled
- Screen Reader : Supported
- Language: : English
- Publisher : IBM Press; 1st edition (October 15, 2013)
- Text-to-Speech : Enabled
- Simultaneous device usage : Up to 5 simultaneous devices, per publisher limits
- Page numbers source ISBN : 0133375625
- ASIN : B00FWSK820
- Lending : Not Enabled
- Best Sellers Rank: #2,046,853 in Kindle Store (See Top 100 in Kindle Store)
- Customer Reviews:
Top reviews from the United States
There was a problem filtering reviews right now. Please try again later.
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.
I think that this book achieves its goal of discussing the problems when you try to adopt Agile practices. I will therefore recommend this book to every software developer and project manager involved in this type of transition.