2010-03-30

Should we ban Kanban?

In the wake of organizations just beginning to reap benefits from agile practices, some of them are already starting to look for the next thing. A natural way to look now is towards Lean product development companies as they seem to have a firm grasp of development practices since decades ago that we in the software industry have been somewhat oblivious to.

Being an early adopter myself, it's hard to argue against trying out new stuff. But when it comes to organizations that find it too hard to navigate their political climate into adopting Scrum, I become a little concerned when they instead jump on flow development, which is inherently even more difficult to grasp and implement.

A brief look at Kanban
Kanban originally was a technique deviced by Toyota to allow workers at different stations in the production halls to signal upstream that more (or less) parts were needed, allowing the workers to control and maintain the optimal flow at any given time. Instead of just sending a note to Buck telling him to "hey, send me more parts, I'm running out", information about the velocity was added. "Hey Buck, why don't you send me five extra units as well, I'm picking up steam here".

The interesting thing about Kanban is when upper limits are applied, essentially giving a tool to limit work in progress thus constraining the flow to the theoretical (and indeed often practical) maximum.

2010-03-22

Using your Gmail as a simple mail Kanban

If you use Gmail, or any other similar web mail, you know how it works - instead of a scrolling list of mail, you get to choose to show 25, 50 or 100 mail per page.

I'm a fan of some aspects of GTD and the way to deal with mail in particular as it got me back in control of the constant inflow of mail to my mailbox for the first time in 20 years or so! But the fact that I had to switch between pages to get an overview of all my mail annoyed me, being an old (and avid) Outlook user.

Then I realized that this was in fact a Kanban limit. (Or a WIP limit to be precise, if we consider queued email to be constantly gnawing away at the back of our mind, stealing focus and causing stress)

Every time the number of email in your inbox reach your page setting (be it 25 if you are bold, or 50 if you are more like me), it's time to schedule a few minutes to process mail and empty the page. Or schedule an email-Pomodoro.

Off you go now, you have reached your mailban limit while reading this!

2010-02-10

The Scrum Picture Debate


There's some discussion regarding the way Scrum is depicted in books and articles.

Although the difficult part about agile work should not be about a process image, I have to agree that I too found the pictures lacking somewhat in focus, always tending to convey the notion that stuff just went through the loops once. As air in a trombone.

In my published material and presentations, I have used this image for a number of years to illustrate Scrum. Sure, any talented art designer would make it much prettier in a moment, and I even left it in black and white (so you can fill in your own corporate colors and put it on the wall - I'm really in a sharing mood today!)

But aesthetics aside, it does help people understand and remember the important points of Scrum.
  • There's the cycle of producing useful things ("Do" and "Release") and pausing for a moment to ponder how things are going, and ("Adjust") the work methods and environment to remove impediments for efficient work. I have given these aspects of the cycle equal weight in the image, to show how constant adjustment is an important part of Scrum.
  • There's the daily/frequent synchronization of work, planning and prognoses ("Synchronize")
  • The cycle itself causes a pull of useful things from the backlog, the flow being controlled and planned by the team ("Plan") and prioritized by the product owner ("Prioritize")
Note that I did not create specific images for the Scrum Master or product owner. They are of course at the table, close to the team, participating in all aspects of the Scrum cycle.

2010-01-27

Software craftsmanship, and a bread machine

So, I bought myself a bread machine. Yes, I'm a sucker for useful technology, and if something catches my eye as an interesting use of technology, I'm already standing in line. Yes, I'm an early adopter, and with that comes equal amounts of frustration and joy.

In my closet of stuff that just didn't cut it lies the old DCC digital cassette recorders (yes, they were the only affordable digital medium at the time, but that didn't make them any better) , MiniDisc (just waiting for increased internet bandwidth to gobble it up) and my robot vacuum cleaner of which I actually have two, as I just couldn't let go of the idea even as the first one broke down from inhaling too much carpet hair and ... eh, dust.

So, where does the bread machine go? Well, actually it's not a particularly new technology, but rather something that has been around for 20 odd years, but dropped out of fashion during the '90s. Fond memories of waking up to fresh bread when I grew up has resurfaced lately. Surely, bread machines must have improved vastly over the last two decades.

So, setting out to buy my household another machine, I noted with amusement that there seems to be a newfound interest in bread machines, as the household stores now carry them, and most of the bigger (and some less known) brands now proudly display a breadmaker in their lineup.