14 May 2010

Agile Then and Now

This past week the Agile Ottawa group hosted Craig Larman for a great session on Scaling Lean and Agile for Large, Multi-Site Teams. There was a great crowd of 60-70 people, and there would have been more if not for a late afternoon traffic problem that closed a major highway! Anyway, Craig said that he has spent the last few years coaching groups on how to scale up Agile to large organizations (of course only as a last resort after attempting to keep things small).

The interesting part of this talk was that it's now beyond obvious that Agile approaches are not only acceptable in large corporate environment, but they're becoming almost required as the business advantage of the approach is becoming clear. In short, Agile is indeed well into the mainstream of the technology adoption curve.

I've been involved in the Agile community for almost 10 years now, and it's quite heartening to see this level of adoption. But let's rewind to the halfway point of my Agile career, to May 2005.

Craig spoke to Agile Ottawa almost exactly 5 years ago, with an attendance of about 10 people. Craig's topic for the evening was Bloodletting. He equated the rate and depth of Agile adoption with the 150 years it took to finally abandon bloodletting as a medical practice. In that case, the proponents of bloodletting literally had to die off in order for the practice to be discontinued. I'm not sure if that's the case in software development, but certainly the sentiment is the same.

So, let's compare Craig's two Agile Ottawa sessions. In 2005 there was a small crowd and the talk was intended to educate us that the adoption of agile wasn't going to be easy (and indeed hadn't been to that point), and some people were never going to accept and would have to die off in the figurative sense. In 2010, Agile Ottawa had a record crowd to hear Craig speak about how to implement Agile in large and very large scale system development efforts. It was not longer 'if' it could be done, but 'how'.

There's still a long way to go, but the difference in the tone of the two sessions certainly highlighted to me that we're on the right path towards much more effective ways of delivering systems.

5 May 2010

A New Daily Standup Dysfunction

As an Agile Coach, I've attended a lot of daily Standup Meetings over the years. I've witnessed and dealt with all sorts of dysfunctions ranging from the usual delving into technical details to attendees mumbling about their work in barely audible tones.

Recently, though, I witnessed a standup meeting dysfunction that was completely new to me - a team member said his piece, waited a minute or so, and then walked away.

First, I was shocked that he did this, but I was even more shocked by the fact that not one other team member questioned his action. Other than the ScrumMaster, I don't think many people noticed. I suspect that the root cause of this problem is that the person in question feels that the Standup Meeting is simply for giving his status.

Providing your status is indeed one aspect of the Standup Meeting, but it is by no means the only reason why you attend. The Standup is intended as a daily synchronisation point for all team members, and I do extend that to include Product Owners. I tell teams I coach that while perhaps 80% of what's said in the Standup may not affect any one individual on the team, the other 20% is absolutely crucial to ensuring that every is working together. Hearing that someone has an impediment may trigger someone to say, "Oh, I had that problem before and fixed it by...". It may make clear the need for a conversation to take place.

Regardless, if you keep the Standup restricted to the 3 questions then it will move quite quickly and that 80% won't feel like much of a waste of time.

3 May 2010

What's in a Name

Several teams at a recent coaching client have been using some form of numbering scheme for their User Stories. There isn't a global standard, but the scheme is consistent within each team. In all of the cases, the teams are not using any sort of title for the stories, just the Story Number and the Description.

An interesting conversation occurred last week when discussing the tasks for a story. It went something like this (names changed to protect the guilty):
Bob: We already did something like this on Story 12a a few sprints back, didn't we?

Bill: I think so.

Brad: Uh, I don't even remember what Story 12a was.
The team finished Story 12a several sprints ago, and all information about it had been archived and wasn't visible on the team's wall.

But that isn't the issue here. The issue is simple communication. Obviously Bob remembered what Story 12a was, but others on the team did not. What if Story 12a had a meaningful title instead? What if that title conveyed just enough information to bring all the team members back to the same page?

A User Story has never been intended to be a comprehensive document of something that you need to do in a system. Alistair Cockburn said it best when he described a Story as "a promissory note to have a conversation", which highlights the critical aspect of stories - the conversation!

The intention of the title and text of a story is to provide enough context for everyone to know what they need to talk about. Throw in the acceptance criteria, and you have a shared understanding among all team members about what a story is intended to accomplish.

The further benefit to using titles is that it also provides context to people outside of the team. Anyone could walk into the team room and understand what "Search for Book by ISBN" means, as opposed to "Story 12a".

A numbering scheme may be fine for providing some indication of relationship between Stories, but it's sadly lacking in communication value. In the end, this whole Agile Software Development thing is about maximizing communication. So, let's do that with the User Stories as well.

More information on User Stories (including examples) is available on the Westboro Systems web site.