In my career, I’ve seen a few projects that had a problem getting “done”. Okay, I was being too nice. Let’s just say: it happens more-often than I think it should. I’ve even had a CIO mock me because I asked him to clarify what he meant by “done”. He actually didn’t know, but he did know that it is easier to blame the programmers, than to define “done”.
When your team is not crystal-clear about the meaning of “done”, you are bound to have trouble getting there.
Even if you have a clear idea of what “done” means, you still might have trouble getting there. Nearly every programmer can tell tales about this sort of thing.
Easy, but wrong solutions
First, let’s look at common treatments, which are NOT surefire ways of getting to “done”. I’m sure nearly everyone has tried these (at some point) and was disappointed to find that they didn’t work:
- Working more hours
- Being more motivated
- Management getting more intense and scrutinizing everyone
- Blaming people
I know you must be aghast that this list doesn’t work. After-all, it seems to be the “top 5” list for a lot of people. Right?
It is especially frustrating when the boss tries some (or all) of the items on this list and it doesn’t fix things. So the boss just keeps trying them with more intensity. “Use a bigger hammer”, I guess.
In case you didn’t already guess, the reason these don’t work is because they don’t address the root cause. It is like bailing water from the titanic, or throwing water on a grease fire.
There is a very short list of things that prevent you from getting to “done”. Which is good, because you just need to identify which one(s) is/are the cause and then focus on fixing it. Once you fix the cause. The path to “done” will be very clear and you can get to “done” pretty quickly. Look for these problems:
- You don’t have a clear definition of “done”: i.e. a checklist of features, and tasks which must be completed. Your list must be specific & clear (no weasel words, no unknowns). When you have that, you can work the list until every item is checked. Management can track it. Timelines become predictable.
- Scope creep: Somebody keeps adding new features or tasks, or the definition of the current tasks seems to change or expand. Perhaps they don’t know the danger of moving the finish-line before the current race is finished.
- The 90/10 rule states: your first 90% of the work will take 90% of your timeline, and the remaining 10% of the work will take another 90% of time. This happens when you leave the hard work (eg. unsolvable, insurmountable) till the end. If you have done that, then you are facing some bad stuff. If you don’t own a time-machine (to start your project correctly), then you can recover by turning all of your focus to the hardest stuff. Consider renting a ninja to help.
- You have been programming, but don’t have all of your requirements yet. Probably this is another form of [lacks clear-definition of “done”]+[Scope creep]. Double-whammy!
The answer to all of these is: close the scope of your work right now. If you have any features which cannot be completed in the next two weeks, then push those features out of scope and finish what you already have. You will probably encounter some friction, but if you thoroughly control your scope (and clearly define it), your timeline problems will completely change and “done” will become clear and achievable. If none of your features are clearly-defined, then you need to direct enough attention to that fact. It will help to justify your actions, so you can divert all of your focus to “clearly defining your features”.
In part 2, I will discuss scope containment, and some philosophies about it.