But people also love company because companies deliver in time what they love in those products. At the beginiing you were like criticising roadmaps and after the midlle you are calling to build 'those' (yours) roadmaps... is the goal to change customer behaviour (29:13) or understand what behaviour is the good one for them and for the business.
A lot has been said about and done with OKR’s. There is no data supporting the positive effectiveness of OKR’s. Without that any benefit is anecdotal and promoting it in a professional environment is wrong. There is nothing wrong with Roadmaps. But consider these as lively things. Roadmaps start out based on wants, and tune towards needs over time in an agile way. This is a continuous proces with Sprints as the only feature freeze focus periods. How you portrait the use of OKR’s in year quarterly periods, makes product development to rigid. Leading to less agility, less results and less fun in creation. Program Increment periods are set on year quarterly basis also. Leading to the same issues of lack of agility, results and fun. Yes, on paper OKR’s as used in your presentation and Program Increments look great. It gives a feeling of being in control. But you aren’t. You never were. Not in the Hi Tech knowledge working arena where people are working on complex things. I know of only one true positive OKR implementation. There, the people were given the opportunity to work on company goal related personal OKR’s when and if they could take time to work on them. Another time OKR’s were forced in to the organisation, and the teams set goals that just allowed them to get budget for things that never got approved earlier. The first example was a big company with a very high level of agile maturity. The second example a big company still struggling with team constellations. So still waterfall team setups, with a flavor of agility. My final point: OKR’s bear in it that too easy old school command & control cultural elements are enforced. Only when companies are at a true high agile maturity level can it be introduced rather safe. Then everything that is not continuous is not natural. Make the objective interval short, like Sprints. The dot on the horizon (product goal) changes position in all dimensions based on empirical learnings. Keep things moving. That’s live, that’s being human.
But people also love company because companies deliver in time what they love in those products. At the beginiing you were like criticising roadmaps and after the midlle you are calling to build 'those' (yours) roadmaps...
is the goal to change customer behaviour (29:13) or understand what behaviour is the good one for them and for the business.
A lot has been said about and done with OKR’s. There is no data supporting the positive effectiveness of OKR’s. Without that any benefit is anecdotal and promoting it in a professional environment is wrong.
There is nothing wrong with Roadmaps. But consider these as lively things. Roadmaps start out based on wants, and tune towards needs over time in an agile way. This is a continuous proces with Sprints as the only feature freeze focus periods.
How you portrait the use of OKR’s in year quarterly periods, makes product development to rigid. Leading to less agility, less results and less fun in creation.
Program Increment periods are set on year quarterly basis also. Leading to the same issues of lack of agility, results and fun.
Yes, on paper OKR’s as used in your presentation and Program Increments look great. It gives a feeling of being in control. But you aren’t. You never were. Not in the Hi Tech knowledge working arena where people are working on complex things.
I know of only one true positive OKR implementation. There, the people were given the opportunity to work on company goal related personal OKR’s when and if they could take time to work on them.
Another time OKR’s were forced in to the organisation, and the teams set goals that just allowed them to get budget for things that never got approved earlier.
The first example was a big company with a very high level of agile maturity.
The second example a big company still struggling with team constellations. So still waterfall team setups, with a flavor of agility.
My final point: OKR’s bear in it that too easy old school command & control cultural elements are enforced. Only when companies are at a true high agile maturity level can it be introduced rather safe. Then everything that is not continuous is not natural. Make the objective interval short, like Sprints. The dot on the horizon (product goal) changes position in all dimensions based on empirical learnings. Keep things moving. That’s live, that’s being human.