Modestly Agile

I read David Anderson’s post on how he manages his sustaining engineering function at Corbis at a time when my team was up to its eyeballs in support requests.  It offered a glimmer of hope.

 I started chasing down the links (what’s a “kanban system”?) and found myself in the conceptual world of lean software development; the Toyota way, thinking about software development like manufacturing, queue management, reducing work in progress, reducing inventory.  Several years ago I read The Goal, Goldratt’s novel about continuous process improvement.  I’d been inspired–I took notes, set up a meeting with others on the management team to discuss how the we could apply the concepts to our service engagements–but nothing actionable came of it and my inspiration faded.  But now, discovering that there was an agile discipline built around those notions I was re-energized.

I re-read Anderson’s post, squinted and tried to figure out the rows and columns on the photograph of a whiteboard included in the article.  I was trying to understand the technique, so I could copy it and get some relief from the bewildering frenzy of requests coming in for my engineer’s time.  I couldn’t figure it out.

Then I had the ah-ha.  I didn’t need to replicate Anderson’s system.  I just needed to start with the basic underlying concepts.  To my understanding those concepts are:

• A fixed capacity for problem resolution–a kanban limit.  In my case, one sixth of the team working full-time on sustaining engineering 
• Prioritization of issues by others. 
• New issues aren’t worked on until space in the queue of work frees up.  This is the kanban demand pull as opposed to demand forecast.  In the world of sustaining engineering the concept of demand is a bit confusing, another mini ah-ha was realizing that real support demand is for resolved issues, not for engineering attention to issues. 

Here’s how I implemented phase one of the system.  I started visiting Karl, the customer support manager everyday.  I didn’t schedule meetings, I just stopped by.  I’d show him the list of things we were working on and those things’ priority order.  After a week or two of this, he had internalized my support capacity (one engineer out of six), and he internallized the concept that once we started working an issue we wouldn’t give up until the issue was resolved.  Our conversations focused more and more on priority, and specifically about what things I shouldn’t work on.  The anxiety level dropped–his and mine.  Here’s a quote from Karl’s weekly account update:

I would like to offer a special thanks to the Engineering Team for their superb attention to the matters we have faced recently.

That’s the result of some modest agility, inspired by readings in lean software development.