My children LOVE the Toy Story movies and, consequently, anything involving Buzz, Woody or the rest of the gang. We picked up a VHS cassette (remember those) which was a bunch of animated (and I mean in the original sense; cartoon animation) shorts about Buzz Lightyear and his adventures in the Space Rangers. It’s a great set of stories, but they’re animated and they’re not as good as the actual movies. The actual movies bring the characters alive and engross me (ahem, I mean, my children) in the story. The VHS is just like a Saturday morning cartoon, entertaining, but I’d switch over without thinking about it.
This parallels the difference between using a whiteboard for a sprint backlog and a digital tool.
Trac, great for ticketing, average for sprinting
I’m coaching two teams at the moment and, while I was still a developer here, I could sense that things had stagnated around the whole idea of scrum. The teams were using Trac as a digital whiteboard and, for the most part, it worked. But one thing that I’ve really begun to notice as a Agile Coach for these teams is that, some impediments aren’t being raised and some tasks are taking a lot longer than estimated in planning. I’m not quite sure why yet, it might be that the teams don’t recognise impediments as impediments, or they’re just really bad at estimating (which, I don’t think is the case).
The other problem with Trac is that it doesn’t encourage communication. It encourages people to write terse, often technical prose in the tickets in Trac, conversations are held there (and recorded) but come on! This isn’t agile! This isn’t face-t0-face communication! Something needs to be done, damn it!
More visibility please!
We needed more visibility on the sprint backlog and I suggested that we go analogue, use a whiteboard, index cards, post-its and sharpies. It took a while and a well rounded discussion (which I’ll go into in another post), but eventually, the team decided to go for it – and I’m glad they did. Already it’s more visible, the board is in your FACE huge and it has a photo of the product owner in a stupid hat on it. The team have started to make it their own and I want to see them create a team culture around the board. Something they can share in, something a bit like a totem pole I guess (although, I’d be aghast if they started worshipping at the altar of scrum (unless they provided me with sacrificial KFC…)) anyway, my point is this: having a white board and going ‘analogue’ means you create somewhere for the team to hang out, discuss their sprint, families, whatever. It’s an ‘information radiator’. Just by lifting my head now, I, and the rest of the department, can see how they’re doing, whether they’re behind, ahead or drawing pictures of stick men dancing. It’s open, honest and truly visible. I think they’re going to love it.
Processed Scrum (as bad as spam)
Another by-product of using Trac is that the teams were allowing it to dictate their process. Using a tool that wasn’t designed for the job or a tool that doesn’t allow you to modify your process as you go is instantly setting you up to fail. How do you try new methods of sprinting, or change your flow after a retrospective? To give you an example, the teams were having some sprints that didn’t have any ‘testable’ features, nothing that could be passed to QA (actually, the didn’t even HAVE a QA at the time), yet, they still dutifully dropped the tickets into the ‘test’ column, which doesn’t sound so bad unless you know the ‘test’ column follows the ‘review’ column. Meaning, each task was reviewed twice – not very efficient.
With a white board (or, in fact, anything you write on yourself. You could go REALLY old school and have a blackboard!) you wipe it clean at the beginning of every sprint. If the team decides they don’t need a ‘Test’ column, then don’t put one in! Similarly, it allows you to experiment with any other element of your sprint that requires recording. Want to try not recording hours, you can (you can’t in Trac). The argument was raised that Trac could be modified to support this – but who really wants to spend the first day of a sprint modifying your sprint backlog tool to support an experiment that may or may not work?
The team were immersed in their digital representation of the sprint. Dutifully updating their tickets, burning down hours and watching the pixels move across the screen, but it wasn’t really a team in full sprint, it was an approximation of one. Much like a cartoon animated Buzz Lightyear is only an approximation of a CGI generated Pixar one.
The only reason you really *need* to be using a digital tool to track your sprints is if your team is distributed, and I mean the whole team. If you’ve only got one guy|gal not sitting with the rest of your team, then a webcam pointed at the team board will do.
(Maybe this is how I will introduce my children to the concept of Agile!)