Real Coders Coding

• Published:September 18th, 2008
• Comments:1 Comment
• Category:Agile Software Development, Scrum
• Share / Bookmark

I was introduced to the world of agile software methodologies and, in particular, Scrum at my last company.  In fact, on my first day new whiteboards were delivered to almost every office and a book called Agile and Iterative Development: A Manager's Guide by Craig Larman was handed out to at least one member of each dev team.  We were told to choose an agile approach that works best for our team and go for it.  However, I later learned that we were to choose any approach we wanted as long as it was called Scrum.  In that effort, I helped to wrangle our usual cat herding approach to software development into something closely resembling Scrum processes.  It was fun and challenging and a very eye-opening experience.

Along the way, we struggled with various ways to maintain transparency so that we could satisfy our higher-ups (or the chickens in Scrum parlance) desire to know the status of our sprints and when we would be ready to deploy, deploy, deploy.  Mostly I'm talking about burndown charts and product/sprint backlogs.  If you have no clue as to what a burndown chart or backlog is... I implore you to follow the links and come back for the rest of the story.  The chickens wanted an easy way to know where we were and the dev teams wanted an easy way to keep them up to date (and out of their hair).  We started w/ Excel backlogs and burndowns, toyed with 3rd party commercial software and ended up with a custom wiki/issue tracker implementation that works but is not very lightweight.  It really involves our internal TWiki, our custom bug tracker and several tools to integrate the two so they communicate properly (involving java, groovy, .NET, XML, etc.).  What we really needed and should have started with was some sort of task board (otherwise known as an information radiator) to make sure we were following Scrum principles as opposed to just displaying data for the sake of technology.

Now, at my current job, we are implementing Scrum but only in spurts (one project at a time) and keeping technology out of the mix as much as possible (at first).  I really wanted to stay away from Excel and wikis and what not and use a task board.  The model I followed came from Henrik Kniberg's excellent paper called Scrum and XP from the Trenches:

My information radiator consists of two big, sticky pieces of wall size Post-It paper, index cards (w/ tape) to indicate major tasks and tons of yellow Post-It notes representing individual tasks.  I generate the grid for the burndown chart online (set to a grid spacing of 2 lines per inch), print it out and tape it the task board.

This works for us so far.  The chickens can walk by and find out how we are doing in the current iteration and the dev team can easily see what specific tasks are left to do and who's doing what.  Eventually, we'll move to a more permanent surface (although the sticky paper and tape is working fine and hasn't failed me yet).  I doubt we'll go so far as actually using electrons to do the representin'.  I mean, c'mon, I'm only a software developer.  Geez, who's got time to write internal tools these days?

I came across a few other examples from various developers across the 'net and thought you'd be interested to see what your peers are working on:

AgileJoe at LostTechies.com

Many examples at mountaingoatsoftware.com

Not so low tech version from Serge Beaumont

From AgileCoaching.dk

Who says you need a wall when a window works fine