(I originally posted this on my MSDN blog.)
It’s often been said that agile project management techniques aren’t a silver bullet that will magically solve all of your problems. In fact, their biggest strength lies is not in solving problems, per se, but rather in exposing your buried problems and making them visible so you can deal with them. For a team switching to Agile it can feel like things are getting worse, not better, but that’s often because they’re being made aware of pre-existing problems they didn’t know they had. It may not seem like it but this is actually a good thing.
Here’s a real-world example. My current team of six people was recently assembled to build tools for an internal customer. I and one other member have a decent amount of experience with agile approaches but the rest of the team does not. I suggested that everyone read the free ebook Scrum and XP from the Trenches and think about whether they wanted to try that approach. Everyone readily agreed that our situation seems tailor-made for Scrum so we decided to go with it.
Our team manager did everything right to prepare for our first sprint planning meeting a few weeks ago. He made sure we had a clearly identified product owner, a product backlog of user stories, and he even printed out each story on a separate sheet of paper and taped them up all over a long whiteboard so we could discuss each one and write notes around them and on them as we made our plans. I was quite impressed.
We started the meeting and after getting through the preliminaries we turned our attention to the first user story on the backlog. The idea was that we were going to talk through about 20 stories to get a feel for the overall strategic direction of the project but within a few minutes we went off the rails. The conversation between the team and our product owner went something like this (not exact quotes, obviously):
“So the first story says the users want to enter information about avails into the system. That information includes these six fields . . .”
“Wait, why those six fields? That doesn’t make any sense. I thought three of them were part of rights, not avails.”
“No, that’s part of avails. An avail means [these things].”
“Dude, that’s not what avail is. You’re mixing it up with rights, and maybe pricing rules, too.”
“What?!?!? Then what the hell is an avail?”
We spent most of our three-hour meeting getting bogged down in the definition of terms and concepts, not getting anywhere near the original goal of walking through all of the stories. At some point during a painful, aggravated silence our team manager gave me a look that said, “Ok, now what, Mr. Agile Genius? You said this was supposed to work. We were supposed to finish this meeting with a sprint plan and that ain’t happening.”
I raised my hand and said to the room, “Ok, point of clarification here. Right now it feels like this process isn’t working, right? We’ve been going around in circles for two hours because we’re not all using the same language. There are several deep misunderstandings that are preventing us from making progress. However, the sprint planning process is doing exactly what it’s supposed to be doing. It made us get together in the same room, talk to each other, and discover that we still have some groundwork to do before we can can even have this planning conversation. The Scrum process didn’t cause this problem, just just exposed the problem. Not having a shared understanding of the domain concepts is a problem no matter what process you use. It’s far better that we discover this problem right here, right now, rather than write a 50-page spec and do three months of dev work around broken concepts before we realize we’re going in the wrong direction.”
Fortunately we were able to work through that particular problem and come to agreement on a shared vocabulary by the end of the meeting. We’ve had a couple more rough spots crop up since then but in each case we’ve identified the source of the problem, solved the problem, and moved on. Progress has not been as quick or as smooth as we imagined it would be but that’s not because Scrum isn’t working for us; it’s because we had a lot of problems to work through and those problems were being made visible quickly so we could identify them and solve them.
Software development is hard work. I doubt we’ll ever find anything that’ll change that. There are no silver bullets. But some processes are better than others for pointing you in the right direction and letting you know what problems you need to solve.
SaintGimp 