Brief tip 6: Do the hard things early

As I mentioned, agile methods have some built-in capability of reducing risk by having a working version early and improving it in increments. In my experience getting an early version up often uncovers miscommunication and can minimize the cost of this.

However, I have found, both using cousins of Scrum and occasionally also methods maybe best described as the evil twin of the waterfall process (!), that there is often a tendency to postpone the hard tasks that we do not know how to handle. Don’t.

In fact, I’d like to advice as my tip #6:

Starting - not just planing, but actually doing - the most difficult tasks as early as possible increases the likelihood of a good result and minimizes the effect of a bad one

Starting working on the hard tasks early has multiple advantages, which include:

• You learn more about the problem domain early on, often this helps finding the final solution even if it will not be finalized until a later iteration.
• Often the hardest tasks in a software development project involve complex integrations and multiple parties. Then it is often length of the calendar time that is required, with the hot potato being passed around, and not so much the number of hours worked that will help. Also the effect of adding more resource when already late has been questioned all the time since the seventies (“Mythical man month”, anyone?).
• Some times the hardest tasks are actually not possible (or at least not feasible) to solve. Finding the workaround or even scrapping the project or functionality early is so much better.

That was my tip #6. Please leave any comments below. My best wishes for the Easter also go out to everyone stumbling across my blog.