Scream if you want to go faster: The development roller coaster
"I love deadlines. I like the whooshing sound they make as they fly by."
Douglas Adams, author of The Hitchhiker’s Guide to the Galaxy.
The need for speed in the development lifecycle of a product is no longer just desired; it is essential for organizations to remain competitive. While this approach breeds innovation, it also breeds terror of upcoming deadlines.
When I first started working in the telecommunications industry in the early 1990s, the average lead time for a complex project was around 36 months. In contrast, the development of most complex phone applications is now around 12 weeks.
You can't fit two pints of milk into a single pint-sized bottle, and clearly you can’t really accomplish 36 months of development in 12 weeks. So what has changed?
The big squeeze
Traditionally, the waterfall development methodology was widely used because it was so simple: do this, then do that and so on. The clear limitation of this was that you couldn't really see what you were building until it was finished.
Added to this, a delay early on would usually not be absorbed, and more often than not it would be compounded by delays in other phases. That was, of course, unless you had an "enterprising" project manager who could recoup the time by reducing the testing phase. I mean testing? Who needs that? All testers do is complain that things don't work anyway!
How does this thing work again?
And what about the documentation? Or rather, the lack of it. As lead times got shorter and deadlines became more frequent, the forests of documentation required got pushed further and further along. It finally became simpler to just document everything at the end of the project. Well, you know what you have built at that point, don't you?
The incremental and iterative methodologies addressed the main issue of the waterfall methodology. Because specific functions of a product could be validated sooner, any issues could be identified and addressed at a much earlier stage.
However, another problem was introduced. In order to divide a project using this approach, a decision had to be made on what to include in each iteration.
How much is too much?
Complexity needed to be addressed. What if parts of one function relied on another part that wasn't scheduled until much later in the development? A function that could be encapsulated in a single sentence might have larger ramifications than the product as a whole.
We need to make sure everyone is on the same roller coaster (and that nobody wandered off to the hot dog stand). Communication between the different stakeholders is vital, as is making sure each person has access to the appropriate information in order to make fully informed decisions. You could use IBM
Wow, those milestones just whiz by!
This approach has evolved dramatically with methodologies such as extreme programming and agile development. Complexity and effort estimation has improved, but some issues still remain.
There is one word I have not mentioned so far in this blog post: requirements.
Requirements are not just the glue that holds a project together, they are the very foundation.
If the requirements are not scoped adequately, the project will be underestimated.
If the requirements are not clear enough, the wrong product will be built.
When the tester comes to create the test cases, unclear requirements will not be adequate enough to fully validate the product.
Understanding of the requirements provides us the basis for estimating complexity, effort and risk.
Regardless of the development method used, if the requirements are not handled correctly, they can be a ticking time bomb. IBM
Always remember that the requirements are effectively a contract. There is a reason that requirements are written as "shall" statements: they are project commandments even though there are way more than 10 of them!
So which ride are you on? Have you managed to successfully tame the development roller coaster? If you would like to discuss further, please contact me on Twitter @ChrisHardy_68.