ND8 DEVELOPMENT
Best Practice Software Development
© ND8
Thursday, July 23, 2009
At the end of Part 1 we had moved from an offshore development approach that had effectively stalled, to an in-house Agile based delivery model, backed enthusiastically by both business and the IS. Eight months later the whole enterprise is dead in the water, having been dropped in favour of a off the shelf package solution. So what went wrong?
Going back to our five measures of operational performance, the new approach was certainly led to improvements on all counts, but in three out of the five the improvement simply wasn’t enough.
Quality - Quality was high, both in terms of producing a solution that met the needs of the business (we had extremely favourable user feedback) and the code base itself, where the numbers of bugs found were relatively low. An unqualified success.
Flexibility - The teams were much more flexible, the iterative approach to delivery, driven through the demo feedback loop, allowed the solution to evolve in a controlled way in the main incorporating change as it came along. Again a success.
Efficiency – Though some streams undoubtedly become more efficient, other streams struggled. In particular re-factoring due to inconsistent implementation became a problem. In addition the build systems became a drag on the development as the size of the code base grew though steps were being made to address this. A mixed bag then on efficiency, but still an improvement on what came before.
Speed – At the end of the day, though the speed of development certainly improved, it was simply taking too long to develop the solution. This could be put down to a number of factors, all of which would deserve an article in their own right, and some of which conflict to some degree with the goals of quality and flexibility. One strong lesson is that the “just do enough” culture has got to be “lived” by the full team. Speed then was not so positive.
Reliability – If reliability is judged through meeting promises, the issue of speed was the nail in the coffin. As we progressed it become apparent that our estimates were too optimistic and projected delivery dates, based on the velocity achieved by the team, started to push backwards.
At the end of the day we found that we could not deliver in a time frame that fitted the needs of the business, especially when set within the context of an overall programme of work that had no end in sight. Speed and reliability had became the top priorities, and in a competition between package or bespoke where these are the critical success factors, there’s only one winner.
The Lessons
What can we take away from the exercise? Well for me there are three stand-outs:
Lesson 1 - When determining what and how to deliver, ensure you really understand the fundamental business drivers and continue to
challenge these through-out the project's life-time. In this case, for whatever reasons, the balance shifted to speed and reliability, and though a package solution had been looked at and rejected in the past, a bespoke solution, despite some of the obvious advantages, was no longer seen as able to meet these needs.
Lesson 2 - Work those estimates. Measure actual velocity and apply it to remaining estimates as early as possible. If the original estimates are not being met, quickly determine why and act to remove any blockages. With iterative development, major adjustments to the overall schedule should be signaled sooner rather than later. If this invalidates the business case, so be it.
Lesson 3 - Embed the “just do enough and no more” mentally right into the heart of the whole team – technical architects, developers, expert users, testers and the rest. This is not always simple, especially when the business have previously been let down on IS promises of delivery, but it is absolutely essential in the control of detailed scope creep.
Bringing it Home - From Off-shore Waterfall to In-house Agile - Part 2