I assert the following (please verify with your own evidence from your past):
1.Time from getting information until using it creates new work (one has to redo the information or one works from old information which results in rework)
2.Time from making an error until detecting it creates new work (e.g., a bug found immediately takes little time to fix compared to a bug found weeks later – that additional work is created by the delay)
3.Shortening the feedback times will shorten these delays and therefore lower the amount of work to be done
Three major actions cause delays (which cause additional work to take place):
1.Working on more things than you have capacity for
2.Working on large batches
3.Working on things in the wrong order.
OK, the above is pretty obvious. We know this. What do we do with it?
Here’s another assertion – you can’t manage what you can’t see. Therefore, if you want to eliminate creating extra work, you must create visibility in how you do your work. Visibility means both where the work is and how the work flows from start to finish. This means you must have how your work is done be explicit. This is one reason why explicit policies are so important.
Kanban suggests you make your work explicit and then you go about improving it. Scrum insists on changing your methods and roles without even studying what your current methods are or what the challenges will be to change your methods to fit the Scrum framework. One says – create visibility and trust your judgment to improve things. The other says – trust us and follow these methods until you have success – regardless of the effort it takes you.