Log in

No account? Create an account
Previous Entry Share Next Entry
Kanban, the Postit's Heavenly Job
Both Jeff and Andy had asked me to share certain pieces of this story..

At work, i've been involved in a web redesign project, where the team was using a modified Scrum-type agile methodology.

In effect: we had a backlog of work, we would have an iteration planning meeting where we would scope out the work, we would work for the week, and then we would wrap up the iteration and present to the steak-holder (or stake-holder, or stick-holder, whichever image you prefer). This was a very fun, focused, and effective way to work. Also, this was my first foray into the professional web world, and I had a LOT to learn (Fireworks, CSS, a full MVP model, a BLL/DAL structure, IoC, etc).

This was all good as long as we were working outside the scope of the normal SDLC/release process, but when it got to be time for the work to actually head out the door - well, several things happened:

  • The process dictates that code shalt not be released without a release
  • The release shalt not be scoped without estimates
  • The leader of the Agile project got layed off (or is that laid off?)

So, we find ourselves, after 6 months of agile bliss, having to switch the entire project over to Waterfall. Needless to say, since we've switched, we've done pretty much nothing to it - mostly estimate out various other pieces of work to see what we can fit into the 300-odd man hours that we SWAGged at early on.

On top of that, we also got swamped in the day-to-day life of ticket work: Enhancements to be designed and estimated, Production problems, and several fixes to the old codebase (that we will be replacing with the new project).

Well, when given lemons, make lemonade.

  • For our release purposes, we created a single-iteraction release in Rally, took the work items, tasked them out, and we're now deriving our % complete numbers off the actual task hours left. It looks like this:

  • On reading Ian Cooper's blog, I found an article, Wither Alt.Net, which somehow, lead me to discover the Limited Work-In-Progress Society Blog, which lead me to an article, Kanban turns around another project, which, along with what its title suggests, also talks about using The Holy Handgrenade as a process for managing database updates.
  • I also Jeff Patton's really nice presentation [PPT] that introduces Kanban for Software Development step by step.

Inspired, and looking for anything to bring back a sense of order to my development life, i confiscated a white board, grabbed some stickies, and made a Kanban board. It looks similar to this:

So far, in 3 days, its been okay. When we do our afternoon "scrum", rather than going person by person, we go postit-by-postit. We added little colored stickies to represent who has which ticket. And sure enough, we can tell when we're getting "full" and work will probably have to queue, or prioritize something.

The benefits, as I can see them:
  • Work, that would otherwise be "invisible" (such as designing and estimating things) becomes much more visible. It seems that I have 3-4 estimation and design tickets in my queue.
  • Rather than person-by-person, where there's a feeling having to prove that I actually contributed something, we now focus on the work that needs to be done.
  • It feels like a team, rather than a bunch of individual contributors who work off tickets assigned to them. At least, for me it does, I can't say for the others.

Its a little confusing, since I'm not the manager, I'm not even a team lead, i'm just the Senior Developer who cares about the health of where he works. Luckily, the team manager trusts me.. we had a little chat as to whether I was stepping on his toes or not, and he asked that please just keep him in the loop. The board very much helps him to stay in the loop.

Its still painful, though, going back to Waterfall. The article above really expressed it well - any time that we're spending estimating work, creating numbers about what we're doing, rather than doing it - its overhead, wasted time. What really matters is a priority list, a very rough form of estimating (story points: story 1 is <=> than story 2), acceptance testing, and multiple points where the steak-holder gets to provide feedback into the product.

Keepin' on Codin' on.