Being able to do multiple concurrent tasks for a story is the holy grail of agile development.  It may not be a myth, but the amount and benefit of it has definitely been over sold. One of the consistent things that I hear that didn’t work well in sprints is that people complain that “this task forced me to rework that task, and it cost time”. This seems to happen most commonly by development changing test plans. However, I’ve heard it from people in pretty much each role at one time or another. Occasionally, I’ve been the one saying it too.

It’s too easy to just say the usual platitudes, “mythical man month”, “can’t produce a baby in one month…”. Blah, blah, blah who really cares? That’s been discussed a lot and no real answers have ever come up. The more interesting question is why do we keep buying into the idea that tasks are completely independent and can be done in parallel? For that matter, why do we think the same thing about stories also? If we start to understand why we think the tasks are independent of each other, perhaps that can provide clues about why this occasionally breaks down.

What does it mean to be independent?

The dictionary definition that best applies to tasks is “not dependent; not depending or contingent upon something else for existence, operation, etc.”  So two tasks would be independent of each other if they not only didn’t depend on each other, but they weren’t contingent upon each other. We have a pretty intuitive grasp of what it means to be dependent on something: it means that this task can’t be started before the previous task is completed. Being contingent on something is a little more nebulous. For tasks, I think that the best definition of contingent is that the details are affected, even though the main structure isn’t.

I think about things more clearly with an example. Two tasks that I see for most stories are “create test plans” and some variation on “implement the story”. People, including myself, normally think of these two tasks as independent of each other, but are they? Let’s start with whether they are dependent on each other. Probably not, a well written story should have enough information to implement the story as well as come up with the test plan for it. Are the tasks contingent? The answer is a little more complex, if the implementation can change details in the test plan, then yes test planning is contingent on the implementation. The reverse is also true, but I have rarely seen development cater to the needs to testing in that way.

Where we get confused is that we equate tasks being able to start in parallel with the tasks being independent of each other. In that scenario, the test plan creation can be started while the implementation is going on, but it can’t really be finalized until the tasks it’s contingent upon complete.

Why do we over sell concurrency?

The main reason that we don’t see what tasks are really independent is that we don’t really want to know. We want each project to have the impression that everyone is working as hard and fast as possible to collect completed stories. The temptation to look busy trumps our rational look at what is actually happening.

There will always be the unexpected items, that we thought were independent but weren’t.  However, we should try to make these the exception rather than the rule. The way to do that is by honest communication and looking objectively at the tasks rather than bowing to the pressure to have everyone 100% busy all the time.

What do we do about it?

When this situation comes up, there are really two ways of handling it. First and easiest, admit that the tasks can’t be done concurrently and serialize the work. Second and more difficult is to make sure that communication about changes in the tasks are communicated effectively.

Not realizing or not caring that tasks aren’t independent is a people problem. The only real solution to people problems are with communication rather than technology. Either option requires open  and honest communication. Whether it’s admitting that the tasks can’t be worked concurrently, or communicating with the people doing the dependent tasks.

The easiest option is to admit that things can’t be done concurrently and just list it as a blocking issue. There is sometimes a phobia about listing blocking issues, but there shouldn’t be.  It’s just an admission of fact, there is something that is preventing me from completing this task.  There shouldn’t be shame, fear, anger or panic in that.  It’s just a statement of fact.

Opening communication about the dependent elements and making sure that everyone knows about changes is pretty much the only way to do it when the tasks must be worked concurrently. Whether it’s by an email, IM, face to face or whatever. First you have to say that this depends on that, so I need to know when you change that so I can update this.