One essential aspect of getting your entire system to be effective is "slack time"—discretionary time for the teams in which they can do whatever they want. Many companies use one day out of the week for "personal projects." Others use this time for learning. 1/8
Sometimes it's whole days. Sometimes it's something like two hours of learning time at the beginning of every day. Use the time effectively. Just don't use it for "work." 2/8
Though, truth to tell, from the perspective of making the work flow as efficiently as possible, the team could just spend the time playing canasta if they wanted. The point is that the slack time is available to absorb variation in the work—to create a "buffer." 3/8
If something takes longer than expected, you can cut into the buffer to get it finished without slowing down the whole system. The whole point of a buffer is that you use it only for unexpected variation. 4/8
If you dip into it all the time, then you need to modify your upstream processes to be more predictable, typically by doing things like making the work-unit (stories?) smaller and limiting your work in progress (backlog size?). You will dip into it occasionally, though. 5/8
That's the whole point. 6/8
A slack time of 20% (one 'free' day a week) is common, but if there's a lot of variation in work size, it may need to be considerably higher—as much as 50%. The approach to tuning is an agile one. Start with 20%. 7/8
Measure your throughput and inventory (work that's waiting to be started or is idle for some reason), adjust to minimize inventory as needed. No number is magic. Start with your best guess and adjust. 8/8
