I'm new to kanban and agile as such but I'm really positive and enthusiastic and I have a clean vision of it's potential for us. I made a decision to start off with a first board and take it from there. Let's visualize and understand ourselves...
I always thought that the development work in the company I work in is a pure CHAOS. Dozens of small (10 - 30min) to medium sized projects/requests thrown at you on a daily basis from a range of (6) product managers / directors of a sort + direct request from customers + customer services girls and data team having their issues.
Priorities change every second day with super urgent tasks requested for end of play tomorrow.
There is 6 of us in the team and each one has got his own niche overlapping each other only from time to time.
There is no such thing as testing the software before deployment.
The developer is pretty much responsible for delivering a working piece of software.
Bug fixing and maintanance is part of the job (actually it's probably more than 50% of the job unfortunatelly).
Big projects just take ages to complete and tend to generate a great backlog.
There is never time for automation, however hard we try and whatever good ideas we have. Technical directors were not helping us (3 of them in the last 5 years).
We are self-organized fire-fighting chaos. Thank God there are still 2 people who's been building the product from the very beginning (8 years ago) - me being one of them. It would be critical otherwise.
Last month I've read Personal Kanban by Jim Benson and I knew it's it. I knew I've got to try it ASAP with my team. You just can't get it wrong, can you? ToDo, Doing (55), Done and bang - you've got board with WIP limit, you can see the flow, you can improve it. Then I was polishing my vision and couldn't fit the board to match us. I just couldn't find the common denominator for each and every team member. There is no such thing as quota for us - the task tend to be thrown directly to the junior developer (by the technical director) etc.
Today was the day when I drew my first kanban board in the office. And I can say I'm not too happy with it. I've done something that I feel is slightly wrong, but I stuck to the idea. This is what I've done:
Backlog | Ready (6) | Who | Today | Doing (2) | Pen | Done
| | Bob | | | | | | ----------------------------------------- | | Rod | | | | | | ----------------------------------------- | | Jay | | | | | | ----------------------------------------- | | Jim | | | |
The first main reason I've drawn it like that was that this is basically how we work:).
The second main reason why I've done it this way is because I don't know how we work.
I don't have a clue how many small maintanance 15-minutes jobs we're doing on a weekly/monthly basis and how does it relate to the new features that are improving the product.
I don't know where the job is usually coming from and what are the 'classes of service' distribution or who is the best multitasker etc.
So I have also itroduced a rather-sophisticated post-it notes system with 7 different class of service (different colours and shapes) and some extra bits to be added on the very card (like the source of the task). I thought that it can't be wrong this way. I'm visualising the work. Not so much I've limited the WIP (it's limited to 2 tasks for each member on the doing column; also the Ready column is limited to 6 tasks - for better planning), but I'm going to focus on completing the once started tasks and limiting the multitask switches (what I have identified as the number one disease that's killing us).
The kanban system will evolve, I'm sure of that.
But the goal I want to achieve is to measure the our team's throughput.
I'm planning to go with the board measuring individuals' efforts for 4 weeks or so. I want to identify and understand the input interface. I want to learn about the efficiency of each members on particulart tasks etc. I need to understand what percentage of the throughput is used for maintanance and bug fixing. Only then I will be able to make a really big step towards improving the process (and not only among the dev team, but a bit higher too).
So, is that a really bad approach? Can you suggest an alternative one? Perhaps it would just be better concentrating on the team effort as a whole from the day 0 and measure the input interface on the team level.