|
|
|
06/06/2012 11:51 AM
|
|
|
Hi all,
The background:
I understand that you should "Visualize Work in Progress" as a key principle of Kanban. This leaves me with a question. To understand a process which may have many steps you could do a value stream map, but in any case these definative steps could become part of my Kanban board. The steps then have explicit "Done" criteria associated with them and we can search for bottlenecks using WIP limits.
The problem:
Many processes occur for a single person in an IT department taking for example a database worker. They may be releaseing production code, code reviewing, looking at new technology etc. etc. Now I can write up a really generic board with To Do, In Progress, Done which will cover everything. The problem is that I can no longer Vizualize what is actually in progress. I can't see where my true bottlenecks are in the process without asking questions.
Should we have generic boards or look to map out each process in more detail on the board?
Thanks, Tim
|
|
|
|
|
06/07/2012 12:18 PM
|
|
|
Hi Tim
Kanban is an inventory control system, but you cannot hope to implement any inventory control system without first knowing the process it is trying to control.
Map out your Value Stream first and than see where you can use Kanban or other control tools to fix problems. Knowing your processes first is key to fixing them and implementing any change and a VSM and its map creation process will help you see where you need or do not need to instal controls, without it you could be doing more harm than good.
Hope that helps.
Good Luck
Robert Drescher
ELSE Inc.
Edited: 06/07/2012 at 12:18 PM by Lean Moderator
|
|
|
|
|
06/07/2012 12:19 PM
|
|
|
Tim, this is a nice question.
I believe that first you need to consider the magnitude of the job to be done, then categorize the work. With large projects to be done or with a tight due-date, the divide-to-conquer approach can makes a huge difference. In both cases, i believe the generic and specific kanban boards are indispensable.
About how to visualize the work in progress, the expertise of the worker and a good method for prioritization can ensure a clear definition of the actual position. A book that i believe can clarify this better is: Lean from the Trenches: Managing Large-Scale Projects with Kanban (Henrik Kniberg)
Greetings
|
|
|
|
|
06/08/2012 05:24 PM
|
|
|
Thanks Robert,
Yes I am doing the value stream mapping and I will be understanding the processes. From that are you saying that if the map brings up an immediate problem then install Kanban? I think from the value stream map I could actually put in performance improvements without running Kanban as it makes issues very evident.
As a mixed mode approach is being suggested, is there a general rule on when to use a specific board? Can you give examples?
Thanks, Tim
|
|
|
|
|
07/17/2012 05:50 PM
|
|
|
Originally posted by: 276104
As a mixed mode approach is being suggested, is there a general rule on when to use a specific board? Can you give examples?
Thanks, Tim
Tim,
Based on my experience with project-oriented production systems, I have a different perception of your situation. It seems that you have a resource-constrained, multi-project environment where multi-skilled resources are assigned to various tasks across projects. If you generate a resource-constrained schedule of all concurrent projects, you would be able to see in the output current work in process (WIP), predicted WIP at any time in future and predicted workflow of all projects. I wonder how effective kanban approach is to control resource-constrained, multi-project environment involving shared, multi-skilled resources.
Prasad
OPTISOL
|
|
|
|
|
07/18/2012 10:41 AM
|
|
|
The story so far:
I have the board split into some generic headings such as Story Prep, Implementation, Review. Under those I have explicit acceptance criteria for each of the different types of tasks (this has proven important). A different colour card represents a different type of task, the colour of writing determins if it's a normal priority task, an expidite task or a fixed date one.
Value stream mapping on each different process has proven useful and we're improving processes as we go where there are delays.
What I am thinking is to use more boards with explicit steps where they add value. I think running this large scale with many different people would overload the board. The problem I have now is external dependencies who we're trying to line up, up front,
What is currently failing:
What hasn't worked too well is the WIP limit. This needs to be sorted as the WIP can't easily be applied to one type of task i.e. there may be cause to work on two project tasks at the same time but then four database changes come in. The four DB changes are small and have external dependencies or cannot be worked on for some reason or another. At present I have limited WIP to 3 project tasks per person accross the whole board. Still working on the rest.
TFS tracking. The board and TFS are kept up to date at the same time, however for small tasks this overhead is not proving useful. I am also struggling to get any meaningful information out of the reports (this is also work in progress).
|
|
|
|
>
Community >
Forums
Send to a Friend
