Difference between revisions of "Abundance of work"
m (So, '''prohibit work on items in the ready state'''!) |
m (Context: {{p|toyota’s six rules}} and a {{p|service oriented organization}}.) |
||
Line 1: | Line 1: | ||
Context: {{p|toyota’s six rules}} and a {{p|service oriented organization}}. | |||
There is plenty of work. No way that you can ask “What can I do next?” twice in a row and not be fired. | There is plenty of work. No way that you can ask “What can I do next?” twice in a row and not be fired. | ||
Latest revision as of 08:29, 19 March 2014
Context: toyota’s six rules and a service oriented organization.
There is plenty of work. No way that you can ask “What can I do next?” twice in a row and not be fired.
So, if you are “out of work”, find new work by starting at the back of the workflow, and work on
- progressing any item if you have the skills; or
- fix a bottleneck if you have the skills; or
- pull in work from the queue; or
- find other value added work that will increase liquidity.
If all this fails, the team composition might need changes. Someone may need to learn new skills in order to improve capacity of the system.
Working on items that are ready to build, that is, as yet uncommitted and unstarted work, violates core agreements set out in the team charter, messes up your statistics, and defeats the core goal of why you started out with a pull system like kanban with work in progress limits in the first place. You might as well stop using kanban altogether.
The work in progress limits are there to trigger conversations and actions that improve liquidity of the system. The limits make problems painfully visible.
average lead time distribution, average delivery rate and predictability inform you about the correct settings of the work in progress limits, not the other way around.
The key thing is that you are disciplined in start what you finish and finish what you start and your team charter.
So, prohibit work on items in the ready state! Make it off limits.