Some Agile Notes from the latest book

Warning: Fairly dry, work-related material awaits the foolish reader who's bored, lonely or desperate enough to read on. You. Have. Been. Warned.

The book I finished this weekend was Agile Software Development in the Large: Diving Into the Deep, by Jutta Eckstein. My boss thought it would be a good book on our situation, since we have over 100 people in the process of "going Agile" right now and that probably qualifies as a large group.

It wasn't one of the best Agile books I've read, but it still had some interesting points that I hadn't encountered elsewhere. I thought I'd capture them here for posterity.

The author stresses the importance of starting small, rather than trying to convert a large number of people from Waterfall to Agile in one fell swoop. She has lots of good reasons for this. We, of course, dabbled in this initially - piloting Feature Teams, for example - but in the end we went ahead and put 100+ people through the Agile grinder all at once. I suspect many of the issues we're now dealing with en masse are probably related to that decision.

On the topic of what sort of teams to form when it's a large group (like ours), she writes about how there are two obvious choices: horizontal (based on type of skills: eg. an analysis team, a design team, a UI team, etc) or vertical (formed around business functionality, with Feature Teams as an example). She actually recommends that you have both types, where it makes sense. As an example, a horizontal team like Infrastructure services a vertical team, like our Feature Teams. In other words, here it sounds like we lucked into the right approach, since we didn't have any real background in this area. Further to this, she makes a strong point for those horizontal teams being regarded, and regarding themselves, as providing a service to the vertical, or project, teams. Some of our groups in this position are still struggline with this relationship, as far as I can tell.

This book is the 2nd or 3rd place recently where I've read that a couple great ways you can deal with groups not jelling with each other (inter-group jelling, not intra-group) are to have a "food area" near one team or the other, so people will congegrate there and socialize, and by locating them proximate to each other. In other words, if we had 2 FTs that needed to work together better than they've been able to do on their own, move them so they're next to each other, and set up a snack table or somesuch that they share. I think both of those are great ideas, personally, and something we should consider making use of.

A new concept in this book is the Communication Team, which, as the book points out, could be as small as one person. "The communication team is responsible for visiting all the teams regularly, obtaining feedback, and discovering deficiencies and (potential) problems..." I see this as a key concept that we've known was lacking in our current setup and we've tried to solve by instituting Project Hub mtgs, or Scrum of Scrums, or daily Integration Mtgs. It's been frustrating for me that we haven't yet established any good means of keeping the Feature Teams in synch: no one currently is really seeing the big picture of the project by assembling each of the little pictures (what the individual teams know), like a jigsaw puzzle. This concept of a Communication Team seems to address this. I suppose, at some point, I could become the Communication Team, flitting like a bee from FT to FT, but then we'd still have the problem of how do I then interface with the folks who are really supposed to own the big picture: the Product Team.

There's a fair bit about having an Integration Strategy and Integration Team, that might be interesting to some at our company. I didn't get that much out of it, except to realize why our core QA and Systems Integration Feature FT are so sure that they're each doing the other's jobs. Probably we need to get some clarity around this in the next several Iterations.

There's the better part of a whole chapter on Architecture and the role of an Architectural Lead, that could be of interest to our Principal Engineers, including one PeterJ. I, however, skimmed or outright skipped most of it.

She's got a few pages on Quality Assurance vs Quality Control, and it's clear that, using her definitions, what we had before was QA, which is all about process, while QC is more concerned with working with the customer to make sure that what's delivered matches their expectations. With our black blox approach to QA in the past, it was never really our QA department's mandate to extend themselves in that direction. But then the author goes on to refer to Tom DeMarco's book Slack, and she writes, "In his book, [DeMarco] presents a list of quality criteria, of which the absence of defects has the lowest prioritiy." Ironically, bug discovery, reporting and tracking seemed to be the vast majority of what our QA department spent their time on (again, largely because engaging our customer(s) was never one of their priorities). This is something we clearly need to address better in our Agile world.

Reading pretty much any of these Agile books is depressing right now once they start talking about the customer because right now we're so far off the mark in this area. It's to the point where those of us in management should almost be dropping everything else we're doing and making the fixing of this problem our Number One Priority. It keeps coming up (I bring it up weekly) but nothing appears to be getting done about it.

There're a few pages on Training that are interesting because they include the notion of creating a Culture of Learning, which is something the boss and I have talked a lot about. Nothing too revolutionary in the book, but there were some good tips that aren't all obvious (have a Review Team, with rotating membership from all teams, that reviews code that's been checked in; identify a change agent for each team, who bring knowledge into and out of their team, and those change agents collectively form a team (possibly just a virtual team); she talks about establishing a Culture of Failure but doesn't really offer much advice on how to make it work).

Chapter 7 is interesting because she recounts her experiences taking a large organization Agile. This was the only chapter that completely held my interest, from start to finish. Some of what she went through absolutely resonates with me, like the various other groups in the company reacting to Agile by either naysaying it and openly expressing the hope that it would fail, while others wanted to jump on the Agile bandwagon even when it made no sense, and the QA/QC reaction of trying to impose more heavy process once they found out how much change was being undertaken by the first group that went Agile. We've seen all of that, in varying doses, happening at our company.