When Will It Be Done?

Everyone likes to know the answer. In fact, this question can be interpreted in many ways, and answered that way too. For example, if we’re using agile techniques, we assume things will go wrong. So what we’re asking really is when is the scope going to be completed.

And that’s not the way agile works, does it?

What we do is set deadlines.  Some of the deadlines are real – like a tradeshow we need the product for. Some are there because someone just put a date on the table. Once we have a deadline, we’re starting our way towards the goal. Iteration by iteration, changing scope by feedback, making the best product we can for our customer.

If we get to the deadline, and there’s no product yet, we’ll push the deadline. Or miss the tradeshow. Regardless, we make a conscious decision about if we’re ready to release or not.

So if we know the dates are set, why does the question “when will it be done” still pop?

If the project is already on the way, what we’re really asking is “Is the scope going to be ready on time”.

Which goes against what we’re trying to achieve: Best value for the customer does not come from a predetermined backlog of features. It comes from the iterative nature of development. When we’re talking to managers who are new to agile development, this is usually what they mean

There’s a bit more to that: Dates are easy to explain. Scope is harder. “We’ll have X baked in, but only some of Y, and a bit of Z”. Managers are there to make decisions. It’s easier to make a decision about a date. With scope you  need to drill down. Good managers drill down to understand the details, so they can make informed decisions. Some aren’t able to make decisions, but we’re not talking about them today.

In that case, we need to explain what we can have by what date. Help them make the decision, and by the way, educate them about the agile process. It may not be our job, but if we want to continue doing agile development, we’ll need management backing. And we’re called to the flag.

Agile-aware people will ask another question, or mean the question in another way:”What can we get in to product by the deadline”. This is an already informed question about how we do things, and there’s an expectations for the answer to be about features. As with any communication, our answer should depend on the knowledge level of the person we’re talking with to explain, but the discussion will be more focused than the former.

Yet sometimes the question is asked before the project even started. It really means:”Is the project feasible?”. Or more delicately, is it possible to do this by a certain date. If the project hasn’t started yet, we probably don’t know much about it. We can either compare it to what we did before, or guess. The guess should not be a yes/no guess. The problem is that the answer “probably” will be translated to an an affirmative yes. What managers want to know is that you’ve actually though about it, so we expect a date range, a plan and assumptions. If it’s not enough, the manager will ask more questions. Let’s remember: management invests a lot of money in a project. Managers want to know they are not throwing it away. They want to trust you, and plans and assumptions raise that trust.

Dates dictates how we manager our projects. Milestones, arbitrary or meaningful, are the driver behind projects. Within the the project time, we should work on what’s best for the customer, realize what we can put in the product and communicate the details.

Communication leads to trust. Without trust, we cannot achieve sustainable agile process.

So let’s work on that, shall we?

Predictability Addiction

I’m addicted to predictability. I admit it. I want my life to flow along, according to plan. Sure there will be some minimal changes, but I can adapt.

I’ve given up on this long ago, as I came face-to-face with real life. I know life is not predictable. And I have embraced change, as agile has taught me.

Or have I?

At ACCU, I had a pleasure of listening to Tim Lister lightening talk about estimation. Tim talked about weather forecast and compared it to project completion date estimation. If experienced weather people can only forecast (Read: DO NOT KNOW) the direction and impact area of a storm within hundreds of miles, how can experienced developers KNOW that the project will be completed on Sep 15th next year?

We don’t. We can estimate, give a range, but we don’t know everything. So we should talk about ranges of dates.
How does that go with my predictability addiction? Not well.

I would like to know when “it will be done”, so I ask the developers leading questions. “If we do this, the risk will be reduced, right? so we can release on…”. Or “Well, we might need to add some small feature X, but it won’t take more than a week, right?”.

My questions are “designed” to give me certainty. I either remove items from the equation, or add a “known” factor to the plan. The answers help me with my addiction… to some extent. In fact, I’m setting myself up for some crushed expectations.

Estimation is just that: estimation. We should reduce risk by not doing crazy things, and sticking to practices that reduce it (testing, anyone)but that won’t get us to certainty. Here’s an example: Our team works in pairs and we have a plan for the next few months. Now one person of the team got promoted, and left the team, so we’re minus one person. How much “velocity” have we lost? Is it just the linear drop in capacity? The thing is – we don’t know. There goes predictability.

Everyone is looking for predictability, but we’re deluding ourselves, thinking we can actually get it. Accepting uncertainty just goes against human nature.
So what’s my take?

Developers, testers, people who produce software: Give ranges. Explain these are estimates, even when the managers on the other side has a similar addiction as myself. And more important – measure velocity, cycle time, or whatever you measure progress with. It’s the past results, and the course corrections that gain the trust needed from managers that your ranges are not over-inflated or extra-reduced.

Managers – Ask for ranges, as well as past results. If you ask, you will receive. Don’t be tempted to ask for a date. Don’t ask (mis)leading questions, since you’ll get them. Since we’re betting the rest of the business on software delivery, it’s a poor starting point. Start from the ranges given, and build from there.

The first step in every recovery is admission. Eleven more steps to go…

Unit Testing Star Wars Style

I’ll be presenting in the Israel .Net user group on unit testing with a star wars twist on May 22nd. So don’t be shy, learn Hebrew, if you don’t know already and register here:



And if you haven’t checked out my latest article “The Developer-Tester Divide” , what’s your excuse? While you’re at it, check the rest of the articles in the publication page.

Image taken from: http://www.quickmeme.com/meme/359jzz/

Related Posts Plugin for WordPress, Blogger...
Twitter Delicious Facebook Digg Stumbleupon More