Another question which came up at Oredev recently:
Q: What do you do when leaders change direction before you have finished your last goal?
I’m sure many readers will recognise this problem, and let’s face it: it can be depressing, you’ve not finished and suddenly you are heading off in another direction. When it happens repeatedly it is especially depressing.
Unfortunately, the term “Agile” implies that one can change direction and change regularly. So maybe this is something we just have to accept? – although depressing, is it really a problem?
Before we try and fix this problem lets acknowledged that it might not be a problem. Chris Matts used to tell a story of a company which when it landed a big enough sale simply threw away what it was working on, rolled back to the last stable release and immediately started working on the new thing. They had rationally calculated that when a sale was big enough it was worth more than the partially done work. (If I recall correctly, they made releases regularly so they would only be throwing away two weeks work at most.)
So, your first option, solution #1, is to optimise your work and deliveries to support rapid changes in direction. One could even argue this was “true agile”.
But, for many teams repeated changes of direction are a problem. They are a problem because the team aren’t able to move forward at all let alone reach a destination. Work which is partially done is either abandoned (and lost) or left unfinished. Unfinished work may increase costs because it gets in the way. We might tell ourselves we will come back and finish it once the panic is over but, as I discuss in always time for tea, that never happens.
So that is the real problem: changing direction is not itself the problem, rather the problem is that nothing is finished. When teams complete and deliver work at the end of every sprint, then as long as direction changes only occur in the planning meeting then there is no problem.
The same applies to more regular changes if the team can finish their work. So, if at the end of every day the team complete some work and deliver it then, if the next morning things change they still loose nothing. True, it might still be depressing that things change so often but it wouldn’t represent a loss.
Thus, solution #2 to this problem: make your pieces of work small and self contained to minimise the loss and increase your ability to roll with changes.
One cause of this problem can be the Product Owner is not doing their job properly. The PO should be peeking into the future and understanding what is round the corner. Sometimes they don’t do that because they lack the skills, other times because they lack the time to do it, but mostly they don’t do it because they lack the authority. They don’t get to visit customers or people in the organization usurp their authority.
So, solution #3 is to fix the Product Owner: make sure they have the authority, skills and time to do their job.
Solution #4 is to go to source: the people causing the changes and work with them.
When I’ve seen this before one of the driving forces was that the people asking for the change of direction didn’t feel the team would be able to complete one piece or work in a timely fashion and advance to the next. Nor did they appreciate the loss that that caused the team when they repeatedly change direction.
Now, if you apply solution #2 and work with lots of small then you can build trust by delivering early and often, that will give you more credibility when asking the direction changers to slow down. But that is unlikely to cure the problem entirely.
Therefore it is important to help those causing the changing direction to understand the consequences of changing: and the fact that constantly changing direction might be the cause of the problem they are trying to solve themselves. To this you need to create a feedback loop so people can see the consequences of their decisions.
One team I worked with would write down the request on a card and take the card and person making the request to the kanban board which showed their work for this sprint. They would ask “Where do you want this work?” The person asking for the change would be asked to decide which work was to be derailed or reprioritised. When this was simply a matter of positioning an index card on the board this was easy to see, the physical act made this really impactful.
Another client redesigned their burn-down charts so the powers-that-be could see that every time they changed direction they increased work and lost what had already been done.
Longer term, there is a question of strategy and sticking to that strategy. Constantly changing direction is itself a valid strategy. It is only a problem when complete responsiveness is not the strategy and when the team are not prepared for it, i.e. when change goes against the strategy.
Having a strategy (which isn’t complete responsiveness) allows one to judge each change request against that strategy. If the change request is coherent with the strategy then doing it makes sense. If not then there is a discussion to be had and there is probably a good case for rejecting the change.
This is not to rule out strategy changes, companies should pivot and change strategy sometimes. However, if one is constantly pivoting and abandoning strategies then it is a sign something is wrong. Strategy, by its very nature, should have some longevity.
Unfortunately, companies often lack strategy either completely or fail to communicate what the strategy is. One Town Hall does not mean everyone knows and follows the strategy. Strategy is embedded in every decision and action of the company leaders.
So, solution #5: fix the strategy.
When ever option you choose Objective Driven Agile can help.
