| Being Agile |
|
Author: Leslie Ekas and Scott Will The subtitle of this book is Eleven Breakthrough Techniques to Keep You from "Waterfalling Backward". Who will they help?
With the help of agile pioneers Tom and Mary Poppendieck IBM has been rather a trail blazer as far as agile methodology is concerned. So this book's provenance gives it a degree of authority that is difficult to beat. In its pages two experienced Agile coaches from IBM, Leslie Ekas and Scott Will draw on their experience to help teams who have embarked on agile but find it difficult not to revert to their tried and trusted previous. Waterfall, practices. The idea conveyed in the subtitle is there has to be a series of habit-breaking breakthroughs, ah-ha moments, in which you really grasp what makes agile different and can gain substantial value from it. Its title is clarified by Leslie Ekas in the preface where she writes: Our goal in writing this book is to give you the means to be agile as well as to help keep you from "waterfalling backward" Or, as she puts it in the Introduction: Adopting agile requires a change in thinking – it's not just adopting a set of practices.
This said in each of the book's eleven chapters, each covering a different topic that is crucial to adopting agile, the practices that are necessary for making a transformation in an agile way are described. These are put in the context of concepts – presented briefly at the very start of each chapter and then expanded in a discussion of the Principles involved. Each chapter also looks at metrics, ways to measure progress, before arriving at its breakthrough – which takes the form of a prescription, usually illustrated by an example from the authors' experience of the teams they have worked with. Six of the chapters are by Leslie Ekas, the remaining five and an appendix (a questionnaire at the end of the book that you “take” to discover the extent to which you've succeeded in the transformation to agile) come from co-author Scott Will. A quick look at the chapter titles is enough to give an idea of what to expect from this book, especially if you've read others on this topic.
This is a book you can dip into, which is what I did for the purposes of this review. Getting customers involved at an early stage is the breakthrough technique discussed in Chapter 2. The big drawback of waterfall development is that customers only get to see the functionality of the software when it is delivered - far too late for feedback. But persuading all stakeholders, including those on the inside such as your marketing and sales teams, to become actively involved, is not always easy. The principles Scott Will outlines in this chapter include "Shareholder Interaction Is Not Optional" and "Do What's needed - And No More". Among practices he notes the importance of setting the expectation of an iterative process in which their feedback will be acted upon so that the outcome will be what they want. One useful point he makes is that if customers request new features urgently they also have to commit to testing it on a short timeline. In the breakthrough section he proposes a technique in which you choose two of you most challenging (demanding) customers, tell them each of them that you are going to fix two issues for them over two weeks. In return the customers have to provide feedback during each week-long iteration and has to put the fix into production. In Chapter 9 Leslie Ekas had advice that seems to go counter to the principles of agile in that it involves abandoning the schedule, albeit temporarily. The idea behind stopping the line, i.e. ceasing work on the current release and concentrating all efforts on a critical problem, is that by fixing its root cause it won't recur and won't cause future holdups. The concept is borrowed from the Toyota production line and can be applied to a wide range of problems including broken builds, broken test automation, poorly architected code and shipping unprofitable products. It can be hard to do as the fix is often costly or uninteresting so teams put up with the problem. The advice is to create a backlog of inhibitors that adversely affect efficiency and calculate the ROI of fixing them. The breakthrough is to prioritize fixing the most significant barrier to customer adoption of your product. Chapter 11 has the overall message: Being agile requires continuous improvement because teams that continue to learn adapt and grow are more productive and competitive. Agile is a never-ending journey of getting better. This was chosen to be the topic of the final chapter since the authors consider continuous improvement to be the most important aspects of successfully adopting agile and is also necessary because no one is perfect and ther'es no such thing as "100 percent agile". The chapter has a brief recap of what's been covered in the book. So if you want a quick summary of the book's messages, its a good place to start! This is a very readable book and if your team is struggling with the transition to agile and the budget rules out engaging an agile coach getting everyone involved, including your customers, to read it could be a very helpful move. Related ReviewsThe Dream Team Nightmare (Pragmatic Bookshelf) Agile Analytics (Addison-Wesley) A Practical Approach to Large-Scale Agile Development (Addison-Wesley) Essential Skills for the Agile Developer (Addison-Wesley)
<ASIN:0133853624> <ASIN:1937785718> <ASIN:143025839X> <ASIN:032150481X> <ASIN:0321821726> <ASIN:0321543734>
|
|||
| Last Updated ( Tuesday, 07 February 2017 ) |