Agile approaches favour building the juiciest bits first – they focus on business value. The Unified Process also recommends business value, but its focus is more on technical complexity and uncertainty, or risk. Is a development team more productive over the course of a project if it is stretched by challenging functionality at the outset?
My first experience of iterative and incremental development was with the Rational Unified Process (RUP). To some extent, RUP contrasts Agile in advocating what should be built in early iterations. When I think of business value I usually think of the functionality that will be used the most, and this usually leads me into thinking of the simple scenarios that crop up in the business 90% of the time.
I recently stumbled across research carried out by Janice Kelly and Joseph McGrath which appears to show that our first experience sets the pace, and if we are stretched early on, it improves our performance and productivity later on. Does this mean a development team’s velocity in early iterations is potentially misleading if the team builds the simple scenarios first?
Don’t get me wrong, I’m an advocate of building the juicy bits first. Work with the users to build functionality that will be used the most, and defer the building of scenarios that don’t occur very often, using workarounds in the meantime. However, if productivity can be improved over the course of a project by tackling more challenging work early on, then perhaps this is worth a thought.
