I admit it, I’m a bit of a geek. OK, I am an Alpha Geek. And yes, I sometimes go with the slightly more computerized solution that others might. I just don’t get Agile’s fascination with sticking hundreds of pieces of paper on the wall, though. Agile teams need a mechanism to share knowledge about stories and tasks. They often do this by using whiteboards with sticky notes (so they can be moved) or cork boards with push pins and index cards. There are columns for the stages (waiting, in process, in QA, done done done) and rows for each story. This article shows an example of one.
I talked about it with an Agile coach friend of mine, Nancy Van Schooenderwoert of Lean Agile Partners, and she made a good point that the paper system makes the whole process easier to learn. She also pointed out that all software has limitations, and it’s important to start out with the index cards or sticky notes so you don’t get the impression that any limitations in the software are a limitation in the Agile practices. I get that. But once the team is passed that point, it’s time to use software-based collaborative tools. Why?
The most obvious answer is it won’t work with distributed teams, which is very common today. It’s not ideal for Agile, but that doesn’t seem to stop companies from trying it. It’s also very common for Software Engineers to occasionally work from home where they won’t have access to the boards.
Unless the team is actually working in the room with the story board, it’s only going to be as accurate as the last standup meeting. I’m sure there are exceptions, but in the companies I’ve known with paper story boards, developers don’t finish a task, walk over to the meeting room with the story board, and update it. And since they’re not updating it after finishing each task, you’re counting on their memory to recall the next morning which tasks they completed the day before (or longer, if they go on vacation). Why put up with that potential for opacity and inaccuracy? Agile is supposed to be transparent.
Paper systems don’t just negatively impact the developers. How does QA know what to test? Do they take the cards off the board back to their desk? Do they take the time to transcribe the cards onto other paper, risking transcription errors? How does the Scrum Master determine how the team is doing? Adding up all the spent/remaining time on a handheld calculator then draw graphs?
There are many web-based, desktop-based, and even smartphone-based Agile systems. I recently found this article which reviewed a few of them. Out of the ones I’ve used, I like Jira with GreenHopper, which even gives you a story board visual. At the other end of the spectrum, I have successfully used Wiki tables to manage simple Agile projects. This is what I use for my team at Agile Bazaar, where I manage a team of four.