Agile development outsourcing one-o-one for startups
The following entry is about our experience in launching transLucidonline, THE simple website publishing system, through our UK entity Pantha Software.
We believed there to be a lot of value in working agile for web-development projects even before we started working on transLucidonline. But then, call it an initial lack of experience in managing a product launch ourselves, we commenced development of the portal site using a waterfall methodology. "Of course", the project did not go well. We specified something that we asked the outsourcing company to develop for a fixed price, they delivered what they believed we had meant and it turned out to be of low quality (in terms of code/ architecture) and not exactly what we had in mind. From there on, it was a back and forth that resulted in more and more "change requests" which in return increased the budget over what had been allocated before to the portal site.
Long story made short: We switched companies, started working agile with them as well as an expert (on Zope & Plone , which we use for the portal site) from day1 on and have since then always been happy with the progress made.
This was also due to the excellent people we were now working with and some of the things inherent in agile development which can be broken down into:
* Planning
We set out with a planning of the major features necessary for transLucidonline. This created the basis for our 'product backlog' which was/ is a prioritised list of features we want to develop.
* Defining the individual features
We worked down our list of features in an iterative fashion with new functionality to be tested on a regular basis. The stories were well defined but did not have the depths (=lots of work) that a "standard" business specification would have. Which meant we talked with our development team on what we had in mind.
* Technical reflection on the requirements
From these discussions, the developers reflected on our business requirements by writing up the technical tasks they believed needed to be undertaken to complete the required functionality.
* Prototyping
Once we had found agreement, the development would commence. Sometimes we were able to see prototypes early on to test and give further feedback on. Most often, the individual features could be completed in 1-2 weeks development time which we felt did not require initial prototypes.
* Testing
Once it came to testing, we would use the user-acceptance tests (UATs) as previously defined in the user stories describing the required functionality. Based on the testing, development would either continue or be "officially" defined as completed.
Overall, thanks also to our unit-testing framework, we have been able to complete quite a long list of features with very minimum up-front investment. Furthermore, this way of working allowed us to continue to run our consulting business while at the same time spending time on product development internally. There was a constant flow, rather than spikes of code to be specified, developed and tested with XPlanner providing us with an accurate, up-to-date view on what progress had been made on a daily basis.
We are never going to go back to the waterfall ways of development and i would recommend any other startup-director to do the same.