“I must not fear. Fear is the mind-killer. Fear is the little-death that brings total obliteration. I will face my fear. I will permit it to pass over me and through me. And when it has gone past I will turn the inner eye to see its path. Where the fear has gone there will be nothing. Only I will remain.”
Frank Herbert, Dune – Bene Gesserit Litany Against Fear
When working on any project that requires estimating how much work is required, then making a commitment to hit some deadline then fear comes into play. However for teams to work effectively, and by effectively I imply they both to the thing right, and do the right things, they must not fear. Fear as my opening quote so dramatically puts it is a mind-killer. Fear will turn a perfectly intelligent set of individuals into a pretty dumb team.
It is my opinion that fear of commitment, fear of missing deadlines, fear of making a bad estimate is the real problem here. Without fear, estimates can be made, deadlines given and commitments made and the perceived negative effectives (symptoms in my mind) will be like water of a ducks back.
The key to giving estimates, deadlines and commitment is simple. They are given based on the knowledge the team have at that time. That knowledge changes and when it does the estimates, deadlines and commitment needs to change with it. This is where fear comes in. First people put off communicating out this new information. This makes the disconnect between what has been said previously regarding any given estimate, deadline or commitment and reality bigger.
As this gap widens so does the fear of communicating the gap. As the fear grows the teams ability to work effectively reduces. That is “doing the thing right” i.e. not making mistakes and “doing the right thing” i.e. working only on the stuff that is needed to hit the deadline.
So for example, if scope or your definition of done change, so you’re knowledge of what you’ve committed to changes, so make sure this is communicated early.
Also if you find that things are taking longer than estimated then use this knowledge to reset expectations about deadlines immediately. We all know estimates are as useful as a crystal ball at times, but you should not ignore the knowledge you’ve gained by doing the real work.
So repeat the “Litany against Fear” and communicate changes early as you’re knowledge of the situation changes.
I don’t disagree in principle to the ‘no estimates’ theme… but teams have to make up for it by over communicating status… As you say give notice on changes to plan often and early. Not get occasional grunts out of the cave that development is still ‘in progress’ with no fixed references…
I hadn’t consciously tried to keep on a #noestimates theme with this post. Here I assume estimates are being used. More that those estimates have a limited shelf life once new information is received that changes the assumptions used to produce those estimates. There should be nothing about agile processes that encourage the “grunts from the cave” behaviour you talk of. Just look at the 12 princples behind the agile manifesto, there is plenty to be said on face-to-face communication, continuous delivery of valuable software and working together with business people. Personally I blame the “protect the team at all costs” mentality of the scrum community that has lead to agile becoming know as the “by developers for developers” process with a return to the less effective waterfall methods by the business.