Avoiding Retrokoma

For those of you working with © Scaled Agile, Inc. and for you working with (or trying) Agile, i here suggest a way to formulate problems to avoid Retrokoma. I wrote about this phenomenon recently as how retrospectives, and i presume the © Scaled Agile, Inc. Inspect and Adapt session as well, has become waste. My suggestion don´t solve the problem, but it creates a structured way of describing it, so we can spend less time on solving and knowing we are solving the right problem along the way. Still – the actions need to be done regardless of format – but i doubt.

So here is my metasolution to the problem. I offer a way to better forumlate the problem statement including the essentials with a strong inspiration from the often used hypothesis statement.

Ove Holmberg

Doubter, gaffer, author