3 ms·

> > Scrum, in accounting for all the engineer’s time in a tightly managed fashion, discourages innovation — which typically occurs spontaneously and outside of

> > Scrum, in accounting for all the engineer’s time in a tightly managed fashion, discourages innovation — which typically occurs spontaneously and outside of any schedule or system of good predictability. > It doesn't. That is why there is a 'focus factor' baked in, to allow for their time to not be tightly managed. Can tap into my experience and say that it does discourage innovation and has nothing to do with focus. While doing innovation and research, your path is fuzzy and unpredictable and does not fit into a predefined scope that the team has to commit on at the beginning of the sprint. While doing research or innovating, you never know if you can deliver business value - your research may succeed... or may fail, which is often the case. Meanwhile, in the predefined sprint scope, everybody is clear what tangible business value it will bring, everything is clear and no room for wiggling and straying away. Edit: I am not talking about occasional research tasks, which seem to fit well into Scrum structure. I was talking about the innovation as a project that requires a big chunk research to be done.

matthewmacleod 8y ago
While doing innovation and research, your path is fuzzy and unpredictable and does not fit into a predefined scope that the team has to commit on at the beginning of the sprint. This is because you are doing it wrong. Innovation and research is valuable. It has a business cost, and may not result in business value in all cases. That's totally fine! But it's still important to recognise that so that we can understand the costs and benefits that are being realised. I pretty frequently engage in long-running research tasks within a Scrum team. The approach that works is to be clear about what the deliverable output is. Perhaps this takes the form of a plan of action, or documentation of the research. If the whole scope of that research project doesn't fit into a sprint, then that's a red flag – break it up. I've had literally no problems with this approach and it's made the process of understanding the business costs of long-running, uncertain projects much clearer.

matthewmacleod 8y ago

While doing innovation and research, your path is fuzzy and unpredictable and does not fit into a predefined scope that the team has to commit on at the beginning of the sprint. This is because you are doing it wrong. Innovation and research is valuable. It has a business cost, and may not result in business value in all cases. That's totally fine! But it's still important to recognise that so that we can understand the costs and benefits that are being realised. I pretty frequently engage in long-running research tasks within a Scrum team. The approach that works is to be clear about what the deliverable output is. Perhaps this takes the form of a plan of action, or documentation of the research. If the whole scope of that research project doesn't fit into a sprint, then that's a red flag – break it up. I've had literally no problems with this approach and it's made the process of understanding the business costs of long-running, uncertain projects much clearer.