Average Reviews:
(More customer reviews)Becoming Agile by Greg Smith and Ahmed Sidky describes how to start your journey to start agile development. The target audience for this book are people who are just starting to look at Agile development and currently have issues. However, personally, I would not recommend this book. The book contains recommendations that I would personally not follow (I'm not that they wouldn't work) and a better alternative might be Mike Cohns new book "Succeeding with Agile" which will be published later this year.
The book contains eight parts and it follows one case study of "Acme Media" throughout the book. Acme media is implementing a small pilot project using agile development. The first chapter of the book describes agile development, the agile manifesto and introduces the background of the case study. The second chapter in the book covers the start, that is the preparation work that the authors recommend. Chapter 4 in this part discusses a assessment test for assessing your agility. The authors recommend to use the test and based on that decide what practices to start with. Chapter 6 describes one of the their key recommendations, which is to form a "core team" which defines the agile process to be used by the organization.
Part three describes the real kick-off of the development. Chapter 10 covers a feasibility phase where the a smaller team will assess if the project is even feasible and after that will be a "gate" or a go/no-go moment so that the project can be killed early. It suggests creating a feasibility study guide to do your feasibility and the authors provide some examples. Chapter 11 talks about creating the initial agile pilot team.
Part four is called "populating the product backlog" where the authors start describing their variant on user stories called "feature cards." It wasn't clear to me why the authors decided to re-invent or rename other agile practices. The chapter describes creating the feature cards and putting them in the product backlog. Chapter 13 discusses the prioritization and chapter 14 the estimation of the features (which seems to be the wrong order to me, but the authors insist on not wasting estimation time). The chapter explains planning poker and story point (wonder why they are not called feature points...)
Part five then discusses the planning (or scheduling) of the project and fills all the requirements to the iterations. Chapter sixteen then starts with the iteration planning of the first iteration. The authors suggest first some modeling and than task breakdown and already doing task assignments. They not that people often recommend differently, but then they assume that it because in these teams "everyone can do everything." It feels like the authors think it is either pre-assigning all tasks OR everyone can do everything... and there is no middle way.
Part six discusses the iteration itself and covers some of the agile engineering practices, but only on a somewhat shallow level. The part starts with chapter 17 which still recommends to run an iteration 0 (even though their project has only 2 iterations!!) Part seven discusses change and adaptation. Chapter 20 describes the adaptations of Acme and why they did it. Interestingly enough, the authors suggest a "adapt week" between their iterations. Then chapter 21 describes the final delivery.
Part eight, the final part, describes how the core group can take the result of the pilot and try to roll out agile in the whole company.
Why I wouldn't recommend the book? There are two main reasons for this. The first is that the book doesn't feel well researched at all and the language is somewhat too 'popular.' For example: page 6 about the Agile manifesto talks about "a group of authors writing a document." Unless you interpret 'authors' very broadly, this is just not true. On page 33 the authors describe weaknesses of Scrum. I'm probably not the most neutral person about this, but still the sentence "Scrum doesn't want specialists" seems like a really odd conclusion and seems to me simply untrue. Another example, on page 248 the authors equate exploratory testing to "company-wide bug stomp." They claim "exploratory testing tries to make sure the software doesn't accidentally do things it isn't supposed to do." If I simply google the internet, then the definitions of exploratory testing are quite different. As a final example, in chapter 22 on retrospectives, the authors do not at all refer to any of the retrospectives techniques described in other places (like the popular "Agile Retrospectives" book).
The second reason why I wouldn't recommend the book is because I personally disagree with a lot of the recommendations done by the authors. These are too numerous to all mention, but to just pick a couple. Having a separate team define the 'process' for the Agile team seems odd to me. Doing a pilot project with only 2 iterations is somewhat short from my perspective. Especially as things like velocity aren't that useful on projects like that. The iteration 0 and the adapt week are things I wouldn't recommend and certainly not on a 2 iteration project. The description of retrospectives are certainly not how I would do them myself. The focus on engineering practices is somewhat shallow. And the list goes on and on. Fair enough, this might be just my opinion against their opinion, but because of this, I would personally not recommend this book.
I decided to go for two stars. Three stars would mean the book does what it is suppose to do, and I don't think it does. One star would be too low as the idea of the book is good. Also, I like the way the authors have build up their case study and the way they describe a project based on their own experiences. The book is not all bad or useless, just not the book I would recommend. Therefore decided to go for two stars.
Click Here to see more reviews about: Becoming Agile: ...in an imperfect world
Many books discuss Agile from a theoretical or academic perspective. Becoming Agile takes a different approach and focuses on explaining Agile from a case-study perspective. Agile principles are discussed, explained, and then demonstrated in the context of a case study that flows throughout the book. The case study is based on a mixture of the author's real-world experiences.
Becoming Agile also focuses on the importance of adapting Agile principles to the realities of your environment. In the early days of Agile, there was a general belief that Agile had to be used in all phases of a project, and that it had to be used in its purest form. Over the last few years, reputable Agile authorities have begun questioning this belief: We're finding that the best deployments of Agile are customized to the realities of a given company.
Becoming Agile discusses the cultural realities of deploying Agile and how to deal with the needs of executives, managers, and the development team during migration. The author discusses employee motivation and establishing incentives that reward support of Agile techniques.
Click here for more information about Becoming Agile: ...in an imperfect world
