Some things break flow and thereby create Tempo Interruptions.
What are the things that do this? Are the types of interruptions they create all the same? Is the way back to flow and making the same?
From the tempo interruptions page:
- When obvious solutions fail
- When obvious work completes
- When the way towards a goal is not obvious
- When there is disagreement on goals
Other (possibly duplicate) thoughts:
- A loss of vision or motivation.
- Blocking errors that one doesn't understand how to correct.
- Errors that require one to drop to a lower level of abstraction to solve. Examples include kernel panics, apparent compiler bugs, memory leaks, performance problems.
- Load that causes a collapse in performance for a system or a team.
- Reaching the bounds of an existing design and needing to move beyond it.
- Applying a new technology to solve an unfamiliar problem.
- Memory Loss about portions of the system. This is akin to using new technology, but without the benefit of a community that can assist with the ramp up. Does this mean that owning a technology that cannot be fully maintained by your engineers is riskier than leveraging off the shelf software (either commercial or open source)?
All of these require Space for Creativity. Failure to do so results in pushing systems and teams into an extended mode of operations which at best tends to produce locally optimal and not globally optimal results.
Can tempo interruptions be reduced in duration by focusing on one source of interruption at a time? Does trying to focus on too many unknowns result in a longer interruption than tackling one at a time? What evidence have we observed on either side of this?