One of the biggest challenges of doing kaizen in office work is to make the work itself visible so that waste can be clearly identified. Much of the time spent in office work is finding files or information, switching between tasks, finding one’s place after an interruption, or deciding what to do next in the face of too much WIP. None of that is true work. We could argue that it is waste. The software development community has taken the idea of using kanban to limit WIP in an interesting direction. I am still a bit at a loss as to what to call the kanban boards used in Agile and other software development environments, since to me kanban has so much other meaning. Until instructed otherwise by a more senior member of the community, i will call them Agile kanban.
Inspired by the examples I’ve found on the internet, and perennially challenged by a task board that is full and growing, I decided to give Agile kanban a try. I have a nice 48 inch wide magnetic whiteboard which until today was just used to write down tasks, attach documents by magnet, and otherwise manage my WIP. The only rules were that I would add things to the board and look at it each day. Being large and heavy, it doesn’t travel well so when on the road the key items for the week go with me in my Moleskine. Inevitably, the list in the Moleskine grows rather than shrinks by the end of the trip.
I bought and cut up dry erase tiles, 12 inch x 12 inch, available in a 2 pack fo r$12.99. On the foam backing I attached business card-sized adhesive magnets. This freed me from paper, and also gave me the ability to move these tiles around on the board as needed simply by picking them up and attaching them magnetically within another column.
This is a brand new experiment so the basic idea is to limit WIP. My inbox was already full to bursting, so before anything further is added to my to-do list, I will need to move them towards the right into “work in progress” or to “delegated”. When things are done, they will come off of the board and the tile will be erased for reuse. It’s also clear at a glance that I am not delegating enough, and this is a combination of improvements needed in communication with the team, making sure people have the skills needed to take tasks off of my board, and making a habit to follow up each day. The blue arrow on the top right of the board is a reminder for me to start each day by following up and / or delegating items to others, and then proceed to the “waiting for” section to see if I can get anything unstuck and off of the board, then onto the actual work of the day. When there is a gap above the blue line, another task can be added. I am permitting myself to multi-task between 3 projects at any one time at this point.
The diagonal lines are there mostly to prevent me from cheating and adding more tiles to that space, and for now also show the “started / completed” dates to give an idea of how long something has been in work. The items below the blue line represent quick “do today” items and we will have to see how many are allowed there each day. Not everything will make it to this board, since making telephone calls or answering questions are not development tasks that belong on an Agile kanban board.
Open questions and remaining issues to be resolved in using this new Agile kanban board:
Defining the unit of work. Since this is brand new I did not make an attempt to categorize items by size or complexity. They are certainly not all equal. A few slow movers could prevent smaller projects from getting done, and this is real life. Hopefully this visualization will help projects move along quicker and the unit of work question will be less important. It’s just blue electrical tape so if changes are needed to this board to accommodate separate streams by size of task, it will be easy.
Defining the limit of WIP. The limit set currently is arbitrary. This will have to be tested. WIP of one seems unreasonable due to the interrelationship between projects and the anecdotal benefit of capturing ideas and using the learning in one development project in another. This requires switching between projects and some loss of time, but I think this loss is the price of learning.
Measurement of performance. I have no good benchmark of personal productivity in the development area. This is something I will need to develop and tie to the volume and speed at which these tiles are being turned, or flowed through the Agile kanban process.
I haven’t done a lot of reading on this and though it was best to try it since I’m guessing that the development work I do differs quite a bit from software development. If you are a a veteran at agile kanban compared to me, please let me know if you have any hints or key points to making this work.