Agile Adoption Patterns

I've just done a first pass through Amr Elssamadisy's cracking new book Agile Adoption Patterns. It's a timely work—enough teams have adopted enough Agile practices enough times that there should be patterns by now. And here they are.

There's a lot to like about the book. I especially appreciate the consistent message throughout that we do these practices because of their tie to business value. Not for truth and beauty, not for right versus wrong, but because they make our customers happy through the means of more money sooner, more often. There is an explicit mapping from various enhancements to business value onto clusters of the patterns. There is also mappings by business or process smell (of which there is a good, short catalogue presented). For each kind of business benefit the patterns within each cluster are logically related and given a partial order with respect to how well they help with that goal.

Separately, the clusters of patterns are described themselves as patterns, which is a nice organising principle. Agile Adoption Patterns is quite explicitly a handbook for finding out why your organisation might want to adopt Agile and then building a strategy to make that happen. A damn handy thing to have.

Scattered through the pattern catalogue there are little diagrams relating the patterns. I might wish for more of these. 

The patterns themselves contain a "Sketch" section, in which a surprisingly large cast of characters play out little vignettes. Dave Developer comes to realise the value of stand–up meetings because he sees Scott ScrumMaster [sic] removing his blockers, and so forth. I know that this style of thing is very fashionable these days, but it makes me cringe. Not only that, but I have a terrible memory for names, so keeping these fourteen characters lined up in my head is a strain.

The patterns have the usual "Therefore" section with the things–to–do in it, followed by and "Adoption" section telling you how to get there. They are all quite meaty, concrete and honest.  And best of all is the "But" section telling you common mis–steps, gotchas, misunderstandings and how to recognise same. This is outstanding! A common shorthand description of what a pattern is (in fact, it's in this book too) is words to the effect of a "solution to a problem in a context" Which is sort–of true a far as it goes but has its problems, mostly around the term ''solution". 

Oh, how we love "solutions" in the IT industry. A more accurate but less compelling description what patterns are is that they are mappings form one context to another, in which certain conflicting forces are more agreeably disposed (or resolved) in the latter than in the former. These "But" sections describe common scenarios (I've seen a lot of them, and so have you, I'll bet: Continuous Integration but continuously broken build, anyone?) that you could have and still make some sort of Jesuitical argument to be in agreement with the "Therefore", but actually are very wide of the mark. The next time I write any patterns, they will have a "But" section.

The highest level organisation of the patterns is into those concerned primarily with Feedback, technical practices, supporting practices and the cluster patterns. I was most interested to note that "Coach" is a supporting practice, but the role of ScrumMaster is assumed throughout.

I am one of the latter, but I'd rather be one of the former. Not so much of an option these days. Well, that's the power of marketing for you.

Meanwhile, one of the nicest things about having patterns is having a shared vocabulary. I think that Agile Adoption Patterns will become the standard reference for talking about Agile adoption, which will make my professional life easier and that of may others. A service to the community.

"Opportunities for Improvement"

The pattern form used is has nine sections and I'm not sure it helps to have each section shown in the table of contents. I feel the lack of a ready–to–hand one or two page list of all the patterns by name. Twelve pages of TOC for 320 pages of content seems a bit excessive. The same syndrome shows up in the index. If all the parts of a pattern are within a four page range do they really all need their own individual index entry? This is really a shame as the book otherwise benefits from the several other complementary ways to navigate it.

There is a stunningly egregious formatting botch on page 207. I'm sure this volume will go into multiple printings and I hope that someone at A–W gets that fixed.

3 comments:

Brian Marick said...

(Pretend this is a blockquote)
... because they make out customers happy through the means of more money sooner, more often.
(end blockquote)

Traditionally, productivity gains are split between customers and producers. Which makes me wonder allofasudden: do people on Agile teams earn higher salaries?

If not... we could say that they reap their reward via a more humane workplace, but that seems incongruous next to your (probably correct) downplaying of "truth and beauty, ... right versus wrong".

keithb said...

Yes, that blockquote thing is annoying, isn't it?

The impression I have form the London market is that Agile practitioners can command somewhat higher rates than the average. As much higher as they should be? Probably not. And "being Agile" may not be the reason, of course, but only correlated with the reason. Or this might just be a co–incidence given who are the people I think of as "Agile practitioners".

Personally, I see this as a very long game: through consistent delivery of value using Agile we are building the credibility necessary to even begin to have a conversation with our business sponsors about splitting the gains. I don't currently see enough organisations that happen to have developers employed (versus, say, Google) where the business model even recognises that building software is anything but a regrettable (and somehow unavoidable) sunk cost.

Meanwhile, I'm happy to enjoy the more humane workplace as a side–effect. It's almost as if, through delivering we get an excuse for managers to politely ignore the fact that we appear to be having fun at work. Damn that's cynical, even for me.

Amr said...

Thanks Keith for taking the time to read the book!

I know how you feel about the "sketch" - I didn't realize they were popular - but I did copy the idea from Fearless Change (Manns and Rising). People either love them or hate them. It's kind of why I wrote the patterns such that you can skip the corny story :)

My favorite section is the "But" section also - I find them probably as valuable (if not more so) as the "Adoption" section. Glad you liked it!

Finally, I'm going to have to find a way to solve the Scrummaster/Coach impression that you got reading the book. That was certainly not my intention. In fact, you'll notice there is no ScrumMaster pattern. (and don't get me started about certification.... grumble, grumble...)

Back to this comment. Thanks for taking the time and effort to read the book and let people know about it, and if anyone is interested in more info, please drop me a line at amr@gembasystems.com.

Amr Elssamadisy