Category: Books (Page 6 of 6)

I will confess at the outset of this review that I did not buy the Agile Adoption Patterns book, rather it was sent to me by the author (Amr Elssamadisy) whom I’d met a few years ago at XP2006. I intended for my review to be as independent as possible but wanted any readers to recognise the potential for bias given the context. The history of the book is an interesting one, combining the author’s own experiences with that of many agile practitioners derived from workshops that he ran at many agile/xp conferences over the course of several years. The benefits for the reader is that it captures the lessons learned of a collective crowd from a number of different contexts, something difficult for a single person to achieve on their own. One side effect of this is that the practices are a little self selecting with many of the practices biased towards XP and Scrum practices (and less of those originating from FDD, DSDM or lean).

I ended up reading this book twice before writing this, although the first time I simply flipped through it lightly to get a feel for the book. I remember distinctly thinking, ‘Yet another book on agile practices? Do I really want to spend more time reading through it?’ The second time, with much more time on a train, I’m glad I did as the author spends a lot of effort setting the context for how to go about using the book.

Given the content, I do feel the title of the book slightly misleading as it talks less about patterns in which people successfully (or unsuccessfully) adopted agile as a whole. Though a good book at what it does, I think it would have been better called, “A framework for adopting agile practices” or “Patterns of agile practice adoption” given its emphasis on the practices and less so on the principles behind them. For me, I find it’s important people recognise the difference between practices (good for beginners during the Shu learning phase) and principles and values (better for the Ha and Ri learning phases) and I’m a little disappointed that little of this seemed emphasised. Of course, this book is not targeted at seasoned agile practitioners, so it fits the audience. I think it bothers me that people thinking that adopting practices alone automatically makes them agile especially when you consider sustainable agile in organisations.

Structurally, the author lays the book out well, setting the context and history of the book and the intended audience. Although he mentions it’s not useful for advanced practitioners, I do think there is value as a means of diagnosing smells in practices for teams that already implement the individual practices. To get the most of out, I would recommend they simply jump to the practices they’re using to see if they recognise any signs of the smells described.

I like the format and I do believe this book contains a lot of useful information although suffers from a small set of problems. One of them is that it suffers the same problem many other pattern books do – it’s a great reference over time, yet a little too repetitive to read in one sitting. Another is that I think this is a great reference for people starting, yet leaves a gap about what to do when you get some of the practices implemented. Often I find some practices are great intermediate practices (iterations and time boxing as a way of developing rhythm) yet doesn’t detail what people should do to ensure agile is sustainable in the long term (dropping practices, and developing their own). My only other issue, as minor as it feels, is that the aesthetics of the book feel really dated, with many of the diagrams and the cover feeling like a textbook I would have used for university.

On the plus side, the author presents a simple, clear and step framework for people to follow when looking at a wealth of agile practices. It’s not prescriptive, and gives a balanced perspective by describing the benefits and the possible less desirable side effects of an individual practice and highlighting the impact of wrongly applying a practice in the wrong context. This is a great addition to the large body of literature on agile that will prove useful for early adopters.

On Wednesday, a whole bunch of IT people descended on McNally Robinson’s bookstore in downtown Calgary to attend the signing of the Thoughtworks Anthology. On a usual week, we’re lucky enough to have two of the contributors in town and unfortunately, one of them, Ian Robinson ended up on a flight from the UK that could have almost taken him all the way to Australia (at least time wise). More fortunately, the other author, Stelios Pantazopoulos (my favourite picture of the night below) made it with plenty of time.

Although I regret being too busy to submit an article, at the time the book was being assembled, it makes me proud to look at the book now and see the breadth and depth of the ideas it contains, and to know that many of my other colleagues share the same level of passion and enthusiasm for really finding more effective ways for IT to work with the business to deliver greater results. It’s wonderful that they can also share this wisdom with the rest of the industry and everyone else benefits from it as well.

I haven’t lived through as many methodologies that Boehm and Turner have, and as a result, their book offers an insights into what the industry has been through. For those who’ve only worked in an agile manner, it demonstrates some of the drivers of more rigorous process driven methods, and for those who’ve only worked in the latter style, shows what a more lightweight process brings to the table.

They even offer a model for you to assess to what degree you need to blend the two for your particular situation. I appreciate the model is driven through a risk analysis of your current situation, and they even acknowledge, albeit briefly, how you might move your organisation towards more agility or less when needed.

You definitely won’t agree with everything they say, yet don’t let that blind you to other important things they do have to say. For example, straight from the onset, I don’t see agility and discipline as two opposing forces. Perhaps agility and defined process is more appropriate. I also find it hard to believe some of the situations they describe, such as when the developer working in a waterfall style tracks how much time they spend, to the minute, designing, coding, on the phone, in meetings, etc. I think all developers I know struggle with a weekly timesheet, let alone tracking activities down to every minute of every hour.

Summary: Every agilista should read this book to gain a bit more of a balanced view of their world.

What’s it about?
Covers techniques and describes the impact of introducing Scrum into large organisations. It also describes why you might choose Scrum to implement and helps evaluate its fit with the organisation.

What I liked about it
Schwaber writes very clearly about some of the consequences of introducing Scrum, including both positive and the negative aspects that I find is very honest and uplifting. He also details some strategies for adopting Scrum incrementally in the organisations. I find it’s refreshing to see many concerns from the enterprise point of view addressed.

What I didn’t like about it
The meat of the book is very short with an appendix describing Scrum taking up almost a quarter of the book. In one way, it’s brevity makes it easy to read though, as a reader, thought more of it was coming. I would have preferred a longer discussion in the book, with an example or set of detailed examples in the appendix instead of a recap of Scrum.