Back in November I blogged about our company trialing Kanban, “Let’s all jump on the Kanban” which we have now extended to our Documentation Team – something described by David Joyce as BBC Kanban Flu.
We kind of knew what was really delaying the release of documentation but it’s not until you make it transparent and have real measurements that it becomes something that cannot be ignored any more. As my old boss Mark Suster used to say “we manage what we measure”. This is where I think Kanban System’s greatest strength lies.
With Kanban we realised that while some of our documents are quickly produced, we have 7 documents in progress being “worked on” by 2 technical authors. I say “worked on” because all 7 are in some way being blocked by a developer who needs to provide input of some type. The average number of working days a document has been waiting for a developer is 14 days.
The documents in progress are waste – they offer no value to the business until we have released them to our clients, and this is costing us thousands!
There are three main reasons why this is happening:
- Developers are moved onto another project before documentation is finished.
- There are few documentation tasks that get placed directly on a team’s boards – and when they do they are mostly given low priority and are at risk of falling off the board completely.
- It’s a job developers are aware of via email but given the lack of formal processes around it, it always can wait until tomorrow, consequently resulting in them never getting to it.
So what are we going to do about it?
I strongly believe that unless documentation tasks are on a team’s board and given the required focus then they become forgotten. So as a result of following Kanban we have initiated some small process improvements in our attempt to improve flow, reduce waste and deliver more value to Caplin.
- A Technical Author is now invited to the cycle kick off meeting to highlight blocked documents, discuss who can remove the block and write task cards which are given to the appropriate Project Leads to ensure these make it on the team’s board for a proper time allocation for that developer.
- Every week we will walk through the Documentation Kanban Board with all the Project Leads working together to remove the blocks and help flow so we can deliver documentation faster and get through the backlog quicker.
We are also exploring how cycle-time could help with the estimation process of when a document is likely to be finished by and thereby giving us more predictability.
I’ll keep you posted on how it goes.
One of I’ve seen of dealing with documentation is described by Pawel in his post here: http://blog.brodzinski.com/2010/02/kanban-board-revisited.html He includes a documentation step as part of his value stream. Features are not ‘done’ until they are documented.
I also like this story because it illustrates yet another non-availability resource constraint (developers not being available to documenters). I believe these types of constraints are not visible yet have major impacts on teams.
Thanks for the link Joshua and an interesting blog. We also discussed about adding a documentation stage on the boards but how far do you go? Do you then have one for writing a Unit Test, Acceptance Test, wireframe, UI Assets etc. All of these are stages in the value stream and it would be interesting if any project has gone down to the level of mapping and tracking the whole value stream from concept right through to releasing the value or in Pawel case Release –> Docs –> Done which I do like.
Personally I feel splitting the process to more stages than you really need generates only additional work.
On the other hand it is a nice indicator something is missing on the board when someone has a sticky note in the hand and can’t tell where exactly the note should be put on the board. That’s by the way how we added documentation column to our board. And pretty much similar story stands behind emergence of design column.
On the other hand if you see a column which is notoriously empty or notes make through it in minutes you may want to consider whether you still need a separate column for the task or it would be appropriate to merge it with another one.
Your Kanban board should evolve as you understand your process more and you start making changes to become more lean . Thanks Pawel for providing two great visual indicators to initiate changes.