Losing my Agile Pixie Dust

April 28, 2009

About 3 months ago an event occurred that I will not soon forget. It was a typical Seattle evening: 4:00 pm and already pitch black outside and raining. I was looking around the office and feeling dissatisfied. Something was amiss and I needed to give it a good old fashioned agile fixin’. So what was it going to be? Should I impose pair programming? Perhaps I should mandate TDD? Maybe we should all sit down together and have a retrospective (and hold hands singing campfire songs)?

Hmmm…No. The team didn’t need any of that. Pair programming is great, but it wasn’t immediately apparent how mandating it would make the world a better place. TDD is great (yeah that’s the ticket!), but the team’s bug count was already super low – so why bother? A retrospective wasn’t going to reveal anything dramatically new since our last retrospective 3 days ago. So what is an agile coach supposed to do? They pay me an embarrassing amount of money to be agile – so I’d better deliver the goods.

I found myself desperately digging about in my bag of agile goodies looking for some agile pixie dust to sprinkle on the team – and coming up with bupkiss. That’s right, I had nothing. Nada. I cast a surreptitious glance around the room. Everyone was working hard on delivering features. Nobody needed anything in particular from me. Maybe I should try something lean like Kanban or concurrent development? No, the situation really didn’t call for it. This was bad. I was starting to break into a sweat.

What was the team asking for? The team had complained about poor requirements, but I really didn’t have an agile tool for that. Of course we had user stories, but they weren’t enough. I can write user stories with the best of them, but improving the user stories wouldn’t revolutionize their world. They weren’t asking for better user stories. The team was asking for more information. More than you could ever put in a user story.

What they desperately needed were better requirements. But that’s not agile, right? OK, every team needs good requirements. And that’s what my team needed – some well thought out requirements. They didn’t need any agile pixie dust from my pouch of agile consulting magic. My pouch was empty. I didn’t have any agile cure-all to give them. Some poor sod needed to go out and dredge up the requirements (or drag someone into the room who knew what they were). No agile magic there – just good old-fashioned requirements analysis.

Gradually it began to sink in: this team didn’t need any agile pixie dust at all. What they really needed was somebody to do some serious, hands-in-the-dirt requirements analysis. Nothing would speed up this team more than decent requirements. They were begging for it. They just needed somebody to listen.

Now I realize that I put some of this description in terms that might seem funny or entertaining, however it is an honest portrayal of my feelings at the time. I literally could not think of any agile solution for the problem and it was a crisis for me. It was like someone had pulled the rug out from under me. No agile solution would work. The only thing left to do was to listen to exactly what the team was asking for: more information.

More information is not an agile problem. We’ve been dealing with that challenge for decades. You can break it up a number of different ways (user stories, use cases, etc.) but one thing is inescapable: the team needs this information.

The more I looked around the room, the harder it got for me to see the agile bits. I was slowly getting a case of agile blindness! I couldn’t see any cross functional team – instead I just saw people working together. Nothing new there. Where once I had seen “information radiators” I now could only see project status charts!

I’d like to tell a story here where I somehow redeem myself. It would be great to wrap up with how I managed to find more agile pixie dust. Perhaps how I managed to regain my agile vision. Unfortunately that’s not the case. I still just see competent teams working hard and communicating with each other. Teams with problems that need to be solved – problems that have nothing to do with agile.

At first I fought this sensation – I think of it as my gradual descent into agile blindness. I really hoped it would all wear off. I would just wake up one morning and see agile solutions to all of the team’s problems again. But as time wears on I’m afraid that’s not going to happen. I see the same plain old problems every day. Problems that an agile prescription (or any other methodology for that matter) won’t fix.

I’ll be doing a tutorial at Agile2009!

April 23, 2009

Agile2009_WebBadges_SpeakerMy proposal “What Nature Can Teach Us About Building Great Teams” Has been accepted! I’m really looking forward to this. I did a similar session last year and it was very well received. Lots of great ideas came out of it.

The Team Touchstone

April 2, 2009

A touchstone is a rock used to compare valuable minerals. If you took a known quality of gold and rubbed it against the touchstone it would leave a streak or mark on the face of the stone. Then you could take a mineral of unknown quality and rub it against the rock next to the first streak you made. A good touchstone would allow a visible comparison of the two streaks to be made. In this case, if the streaks matched, then presumably the second sample was also gold. If they didn’t match – no gold. Sometimes an acid might be applied to the streaks to further help clarify if they were the same substance or not.

So a touchstone is a tool used to compare the quality of two samples. It occured to me that as Scrum Masters we also act as a touchstone for our teams. Our job is to help the team see how the changes that they have made have improved the way they work. Of course we need to have a starting sample to compare against. In this case, the starting sample – what we might think of as the gold standard – is plain Jane, do it by the book Scrum. Scrum is our starting point. It is the process baseline against which we compare our process improvements. Some might argue that any process would work as this standard, but I think there is a certain elegance and simplicity to Scrum that lends itself to using it in this manner.

So we put Scrum into place for our teams and establish a baseline, We try it out for a sprint and review how it works for us. Then we change it. We tweak the process to make it work better for us. We try out new ideas, new practices, new ways of working together that enable us as a team to potentially perform better. How do we know the changes are an improvement? By comparing them to Scrum.