I recently came across this video on deadlines and it helped crystallize a Blog Post that I have wanted to write for a long time.
Although the video is quite good an makes some very valid points, I fear the Agile movement is starting to exhibit some concerning signs. There are more and more Agilists proposing that we should not estimate or have any deadlines. I use the term Chicken Little in this Blog entry as I usually encounter exaggerated “the Sky is Falling” arguments when I propose that estimates and deadlines can be applied in a judicious manner and when managed properly, can result in greater value for the team and the project.
“The term Chicken Little has been applied to people accused of being unreasonably afraid, or those trying to incite an unreasonable fear in those around them” – Wikipedia
Let’s start with estimates. It seems to be very fashionable to propose that estimates are useless and a wasteful exercise. Usually when estimates are mentioned the following Chicken Little cries are heard:
- You are proposing detailed estimates
- You are proposing estimates made by someone out side of the team
- You are proposing a detailed work breakdown structure
- You will punish the team when they don’t meet the estimates
- We are going to spend a month creating detailed estimates
Of course all of these cries are usually false unless poor project and company leadership exists. (If poor leadership is present, they will find other means to oppress the team without estimates and deadlines) These are exaggerations intended to make a point and portray the worst case when estimates are misused. Typically the opponents of estimates will also state that people are bad at estimating. The Beyond Deadlines video even makes this point.
Although estimating is a difficult activity, no one usually discusses how estimating is a skill. The reason people are bad at estimating is because it is a practice that they may not have been exposed to. No one ever discusses how people get better an estimation the more they estimate. The usual cry is that estimating is hard and we suck at it so we should never do them again.
In our company we have two rules:
1) The team creates the estimates (and plans) in all situations. They are never changed or modified by anyone but the team.
2) Friends don’t let friends estimate alone.
Most of the negative experience and stories around estimates propose situations where people are estimating alone and for the first time. (see rule #2)
Deadlines are starting to become the new cause célèbre of the Kumbaya Agile movement. The history of the word “deadline” is reviewed as a line when people were shot. It is proposed that if you use deadlines, you must not trust your people and believe that people are inherently lazy. Once again we see the extreme hyperbole to try to make the point.
Once again the use of deadlines, or milestones and target dates, can be a very useful method for planning a project. The use of them, does not mean that you don’t trust people. In fact, many people I have worked with ask for a planned end date so that they can use it to guide their work and prioritize.
The negative reputation of deadlines lie in the history when deadlines were created by management and foisted upon the team. Like estimates, deadlines or milestones need to be created by the entire team collaboratively.
Many opponents of estimates and deadlines propose that they can affect behaviour and damage intrinsic motivation. I would argue that this again is only evident when estimates and deadlines are used inappropriately.
We don’t need estimates and deadlines to motivate people. We need them to assist in planning the project.
Estimates and Deadlines have been used in the past to oppress and punish people. We should be careful to not allow these situations to happen once again. But we do need to be careful that we do not propose elimination rather than moderation.
Just as the extreme application of estimates and deadlines was a mistake, so is the extreme eradication of them.
Why are estimates and deadlines a good thing? Because they require the team to plan. The elimination of both estimates can lead to a team not planning enough and this can have a negative affect on the project. The definition of plan I like is:
“a temporal set of intended actions through which one expects to achieve a goal.”
When we are evaluating project practices we need to be careful to not eliminate practices that are hard for the development team if they deliver value for the clients. We need to remember to do just enough of these practices to allow us to deliver the most value.