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.