Saturday 16 January 2010

Personal Kanban for Just-in-time skills development

It is not uncommon in IT projects that you are required to learn something on the fly or you see an opportunity to introduce a new technique or tool that would bring great benefits to a project.

How do you manage the learning curve required for something new without major impact to the project?

After reading comments from my previous personal Kanban post by Jim Benson and Bruce, I thought I would expand on the Just-in-time aspect of Kanban.

I currently use my personal Kanban (LeanKitKanban) to drop small size cards into my backlog that are designed to tell me what I need to learn about a subject or tool quickly.  The cards have a set goal that should be manageable in a short time period.  Each card would have the relevant resources links to help me achieve that goal.

When I get a spare hour I can select one of these and have a focused, time-boxed cards and get up to speed quickly.  If I have met the goal and feel confident that what I have learnt was beneficial (either personally or for current work) then I mark that card as a success.  If I don't meet the goal, then I will mark the card as incomplete and review it in a mini retrospective.  The goal of the retrospective is to help me write better cards quickly, as well as check that the topics I am learning are coheirent.

An example would be good right now:

I was at the Agile Testing user group in December and there was some discussion on continuous integration.  I realised that this area has really flourished since I last set up Cruise Control, so I created a group of cards on my Kanban to look at what's new in continuous integration and to reaffirm that I was up to date with the latest practices.  In that same week as the meeting I had manage to review the theory (Google, Wikipedia) and learnt a new tool called Hudson (great tool, I recommend it, neatly integrated with Netbeans).  All this was pretty easy to fit into my busy schedule as I could easily visualise all my work on the Kanban and see what was important that week and what could wait.

I still have several continuous related cards in the backlog, but for now I have refreshed enough theory to work with Hudson effectively in my project work.  If I need to learn Team City or some other CI tool, then I have a model to quickly tackle that learning.

This approach works for me at present as I break down the task on the card to something managable.  I am curious to find out how well I can break a large subject area down with this process, for example learning the whole of Spring 3.

For now I will be using this JIT Kanban learning to review and extend my Behaviour Driven Development (BDD) skills as I have a BDD immersion workshop in February with Liz Keogh at SkillsMatter and want to make sure I get the most of the workshop.  It should be a great day of learning as Liz has done a great deal of work defining BDD and adding lean system thinking into the topics that will be covered.  There will be some homework to take away from the course, so I'll be using my personal Kanban to organise that work into my busy schedule.

3 comments:

  1. I love where you are going with this.

    I was managing agile teams since about 97. When we started doing Kanban in 2006, we were under the radar. As Kanban started working its way into the mainstream, people started to think there was some Agile vs Lean dichotomy.

    What lean showed me was that Programming is not the special garden we thought it was - it's knowledge work. And that understanding led to huge advances in how to use Kanban effectively.

    It also meant that it was suddenly easier to take agile principles and apply them outside of programming.

    You've created a manageable and traceable system for knowledge Spikes. Spikes being taken directly from agile and the management being Lean.

    That is taking the best of both worlds and I applaud it.

    Jim

    ReplyDelete