Personal Kanban

Personal Kanban

I’ve been doing personal Kanban at my current assignment for the last two/three months. A colleague had previously told me he was using it at home, and I wanted to see if I could benefit from it at work. Now, I didn’t actually look up the ‘correct’ way to do this, but instead opted to start with my current conception of the method. There was a leftover piece of cardboard laying around, so I took that and drew two lines on it for the ‘todo’, ‘doing’ and ‘done’ phases. On the bottom of the board, between the doing and done phase, I put my own ‘definitions of done’ to remind me of what it should mean to complete a task. The criteria I chose initially were

  • Reviewed (by myself),
  • Unit tested,
  • Javadoc written,
  • SoapUI/Selenium tests created and run,
  • Maven build and tests run,
  • Code committed,
  • Time spent reported into the time reporting software.

You can take a look at the picture below for the setup. Nothing revolutionary of courseā€¦ I chose a WIP-limit of two and that’s been quite sufficient so far.

Personal Kanban Board

My experiences thus far are that I have become a little bit more structured and focused; I’m more aware of my current work load; I’m a little bit better at keeping track of tasks (the smaller ones that can easily be forgotten); and I’ve got an easier time filling out the time report for each day. Of course, the benefits of the method have not revolutionized my work day, but with the minimal effort involved I’d say the experiment is a success.

I’ve learned some lessons: that the company supplied post-it notes keep falling off the board, so I should look into buying some top quality ones. I also found that I sometimes put up a task on the board of too large scope, and that I failed to complete it quickly enough. That meant it clogged up the doing lane, while I had to expedite other urgent matters. I should have broken the task down into smaller ones, clearly!

As an experiment, trying out personal Kanban is something I can recommend. You should see the mentioned benefits quite quickly, and if you’re new to Kanban, you should get to familiarize yourself with the concepts. If you want to know more about this please visit Jim Benson’s Personal Kanban site!

Shelving Changes

Imagine that you’ve been working for a while on a particular feature, and that the code is versioned under Subversion or some other VCS. You’ve made changes in a couple of files but you’re not yet ready to commit. Then suddenly you need to quickly switch to another task because someone in your team needs a bug fixed. Or perhaps, you need to fully switch focus to another feature, because unfortunately someone re-prioritized in the middle of your iteration! This could get messy, especially if the features intersect code-wise. I bet you have (at least some time during your career) copied the modified files to a location outside your project for storage, and then merged them manually when the time came to start working on the feature again (it’s OK, noone can see you nod :-)).

A decent way of solving this situation in IntelliJ, is to use the neat little feature Shelve Changes. It works sort of like an extra local layer of VCS. Just go to the Changes tab, right-click your modified files and then Shelve the Changes. This puts them in a shelf on the file system, and removes them from the list of modified files. Now you can continue working as usual, committing and updating your local repo until you want to Unshelve the Changes. Should there then be any conflicts, IntelliJ provides a merge tool.

Obviously, this is even neater if you start using Change Lists properly. Then you have all the modified files grouped under the change list, and you can then easily Shelve the entire change list.

Finally, a word of warning since this type of local versioning is prone to all the usual problems with having local copies. It’s best used in rare cases when options are limited, and you are prepared to potentially losing all the changes due to a system failure.