Agile 2006 Conference

What a gas. I've been back about a week playing catch-up, hence the tardiness of the post. Quite exhilarating to meet so many like minded people. It was great to meet so many people in roughly the same boat as us (i.e. just getting off the ground).

In a highly unscientific study, I discovered that most Agile process rollouts are sitting at one year or less. About 65% of the people who were doing agile (any agile process) where still at the one project or "Pilot" stage. While the talking heads kept repeating that everyone has unique problems requiring individual solutions, my observation was that people tended to hit the same stumbling blocks - most notably, integrating the test process. I might even call this "Extending Agile beyond the core development team." More on that later.

Two main things struck me about the crowd:

1. The relative lack of "I drank the kool-aid" fanaticism.
2. The wide swath of people from the organization participating
   

While there are always true believers in any crowd, by and large people's excitement seemed tempered by the difficult realities of trying to roll out an organizational business process change - which is essentially what we're trying to do by moving from SDLC et-all to Agile.

I'll preface this by saying that we're a Scrum shop and biased, but my two favorite speakers where Mike Cohn (Mountain Goat Software - Agile Estimating and Planning) and Ken Schwaber (co-creator of scrum with Jeff Sutherland). Mike is one of those jovial, bigger-than-life types that you instantly want to go have a beer with. His estimation stuff seems obvious in retrospect, but that's true of all good ideas. Ken is more soft-spoken and profound. The way he talk - anecdotally with personal experiences - makes it seem easy. But the quote he repeated many times was "This is hard stuff".

Who I didn't particularly care for, surprisingly, was Kent Beck (creator of XP). He was a little too metaphysical for my tastes. He spent a half hour (his allotted time in the session I saw) talking about courage and integrity and some other crap, never once actually XP practices, what they are, and how they work together. Of the speakers at the conference, he has definitely drank the most kool-aid.

New staffing

We're bringing on a new staff member and now the question is how to integrate him into the team. On traditional projects the MO I've seen is to have them read any documents (in whatever state they are in) and gradually assign them a functional section of the product. This has not been an optimal solution for a few reasons:

• The functional are "to be assigned" languishes during the hiring process
• Current staff is often unwilling to help the new dev become productive (or unaware of the fact a new dev is being added)
  
• If a functional area has not been earmarked, the new dev often does menial tasks (docs, exception handling) until the next version - often quitting before then

So does agility help this? It can.

1. The master backlog is filled with encapsulated and bite-sized tasks that are already identified and constrained for development.
   
2. High priority items are always addressed first, you don't end up with functional blockage due to staffing issues - everyone is cross-functional to some degree.
   
3. A structure already exists to validate the work of a new team member (via the acceptance tests).
4. Development failure within a given story will be (somewhat) mitigated since coding tasks are organized into quasi-independent units
   

Basically, you are continually doing the organization required for bringing on someone who is of a different level than the other team members, so disruption to the team and project are minimized.