Following on from the previous post, here I’ll talk about moving over to LeanKit and introduce a few more concepts as well. The board, I feel, is still a work in progress and I’ll talk about this as well and also relate back to situations in your work environment at times as well. Also, a warning, this is getting into more advanced topics and for simple Personal Kanban boards, what follows may not be necessary for you.
As mentioned, I found Trello to fast become limited in all the information I wanted to include on the board. LeanKit is a step up and the free version offers a lot more capability. The paid versions also offer more like Class Of Service and Graphing like the Cumulative Flow Diagram. Towards the end of this article you’ll see that I’m also getting to this point where I’d like these features as well.
LeanKit has a number of templates ready to go as we can see here. Great, they’ve provided a quick start to begin with and then tune and adjust from.
There are some great looking starting points for other value streams like the Portfolio Template (this could/should be applied in each PMO). Naturally enough I chose the Personal Kanban Example and the first instance of this shown below and it a dump of the Trello board. I ran both Trello and LeanKit side by side for a week or so too smooth over the transition. The ToDo column was further broken down as per the template to SomeDay Soon and SomeDay, illustrating the need to instantly visualise what’s important.
The immediate concerns with this board was the correctness of the lanes and the sizing of items. The lanes were mostly correct but since this snapshot I’ve added more lanes and renamed others. My other concern was with sizing as well.
On my Trello board I took the advice of Paul Klipp and colour coded the items. The colour coding used t-shirt sizing that corresponds to a number of minutes for a task or job:
I found this useful in the prioritization process, but (I think) this as far as I can go with Trello. I would also like to use a priotization in terms of criticality. LeanKit has this out of the box. With sizing though, I decided to go with fibonacci numbering as LeanKit can only accept numbers into it’s sizing field. In this case I’ve also gone with more explicit relative sizing rather than the explicit notation I used in the Trello board.
I did start with a mapping somewhat to the trello sizing though and with this an item that is estimated as a 0 is essentially an XS and a 1 was a small, 2 is 30 minutes. However I’ve now found these sizing to be too fine grained for my purposes and the relative sizing has now changed and more related to the size and complexity of the work item as compared to each other and I dispense with the idea of linking to time. In fact time fluctuates but they do seem to remain with a bound.
However this is not yet backed with hard data, LeanKit – the free version, doesn’t provide these. But I feel this is not that important. I feel it’s better to deliver the work items with the terms of a Service Level Agreement. I will probably need to upgrade to LeanKit to start tracking this so I can develop the policies with the backup of this data. I feel like I’m coming on board (or understanding) this idea of the #NoEstimates movement.
I’m hoping to come to the point where I don’t waste time agonizing on the estimate (and I don’t really), and rather find the right slot for the work and just get on with it. When a task ends up taking longer there will be a reason and a chance therefore to reflect and reason about the (root) causes for the failure. The results will have to appear in a subsequent post. I do feel strongly that we waste far too much time at Work agonizing over estimates trying to be perfect. This is impossible and we should just get on with the work, but do it in small batches and regularly reflect on the outcomes so we can learn.
Over time I realized that not everything was being properly represented, i.e. not all work was present and this was not being truthful. I added weekly habits as repeating tasks (these don’t need to be recreated all the time) as seen here but also became more diligent is recording and reporting all work.
This also shows the breakdown of bigger ticket items into projects (far left). I also have a number of ongoing projects which do need further breakdown as well. These could be boards in themselves – will see if that is needed, but for now I’ll try and manage all the work here. It is however becoming a bit more difficult to manage in terms of WIP Limits.
The InProcess column represents, for me, all the work in process. So whilst it says maximum of 4, It can actually display less as a big ticket item remains there as a placeholder. In this example the User Stories Course creation task is broken down into into own project and it’s own WIP limits, but I need to be careful not to over run the total WIP limit and this involves some quick mental arithmetic to check against the current Daily and Weekly Tasks and the Projects tasks and to fill up the Today and InProcess columns paying respect to the overall work in process.
I’ve also added an Expedite column. This is a vertical column, but actually this is a special class of service and should be a horizontal column across the entire board. It doesn’t seem to be possible to do this in this version of LeanKit without an upgrade. The Expedite column essentially trumps all other work. It can exceed the WIP limit of any column, in my case, but there is only one item allowed at any time in the Expedite column to prevent this from becoming a bucket for all work.
This is a handy segue onto, The Pen column. This can get out of hand and recently I’ve felt this has become a place to put stuff a bit too hard to handle. When it gets too large it means I need to knuckle down and find out the issue for the delay and get on with it. The the biggest issue is dreaded procrastination. For instance I had Fix the Lawnmower in there for a long time. I just didn’t want to do it. I know that I should and need to, given the state if the lawn. I’ve taken the measures to sort this out. The mower is the repair shop being looked at.
I should also mention the colour coding and other adornments. Some people find it useful to use different colour cards to signal different types of work. For example I have a range of colours from White (Read a Book), Purple (the Home) and the yellow is a generic task – a catch all for everything else. Some cards also have Priority assigned and Estimates and these are visible as adornments on the cards.
Use a Pomodoro
Another technique I’ve introduced as well to prevent overwork is the Pomodoro technique. Without getting into reams of detail, essentially I work for 25 minutes and then take a 5 minute break. I use http://tomato-timer.com as a timer and there are apps for various mobile devices. I do find this useful to remain focused on a task and to shut out other distractions whilst I’m focused on the task.
I think the way I’m handling the WIP Limits will be an ongoing issue and will need to be closely monitored. Maybe just having one overall In Process Column is best and I might try that out.
Overall, I do feel I’m making great progress. I’m seeing more of what I need to do and what dangers lie ahead if I’m not careful. There will be more data to fill this out a bit more. When I upgrade I’ll write more on the metrics I’m getting from the system and that should be an interesting read 🙂