With the business world operating on ever decreasing lifecycles, achieving faster time-to-solution is becoming a critical success factor for the software industry. Trying to deliver stable software solutions, keeping up with the speed of changing technology and meeting the expectations of ever demanding customers is a constant juggling act for software industry consultants.
Cloud-based ‘Platform as a Service’ (PaaS) environments have greatly reduced hardware infrastructure provisioning effort; the challenge now if for software development to take a similar leap forward in speed and efficiency. The tools are available to produce software in weeks or months instead of years, but a new approach to the development lifecycle is needed to fully leverage these developments.
Traditionally a standard software development cycle would look something like this -
This ‘waterfall’ model was appropriate when technology was moving slowly and it was hard to demonstrate progress until the end of the project. As technology evolved at an increasingly rapid rate, it was clear this model could not be sustained. There is ample evidence that this methodology produced high rates project failure; some projects were even delivered with technology that was out-dated before ‘go live’.
Enter agile delivery methodologies! The agile approach is aimed at reducing the planning horizon and shortening delivery iterations (generally two weeks) so that adjustments can be made ‘on-the-fly’ throughout the development project. This is illustrated in the diagram below.
The regular feedback loop inherent in an agile approach greatly increases the probability that delivered solution align with the needs of the users, even when those needs have shifted mid-project (as they often do!).
Successfully transitioning to an agile approach is not without challenges. Following are 3 common traps for the unwary -
- Analysis is focused on moving the current processes onto a new technology without first optimising the process itself. Optimising business processes should be the first priority and determining the technology solution second.
- Many agile projects still start with a full specification of the system, often based on current processes. This is due in part due to the requirement for documentation to ‘sign off’ and in part it is habit and comfortable for many consultants and sales people.
- With the mindset that development time will be greatly reduced, customers assume that change management effort will also require less time and cost. This is incorrect and where many projects will fail if underestimated.
The resulting hybrid development cycle is illustrated below.
Writing a full specification document for an agile development project is a waste of time and money.
Developing specifications up-front based on assumptions and theories requires a great deal of effort and the results are inherently flawed … incomplete, inaccurate and out-of-date. The nature of agile development means that the highest priority functionality is delivered first, at the time of building; it is rarely, if ever, what was considered high priority at the start of the project. As a result, the final deliverable is not exactly aligned with the initial concept, making up-front sign-off ineffective. The inherent allowance for changing requirements facilitated by an agile approach means that the specification document will need constant updating too, a very time-consuming and costly overhead.
"If it can’t fit on the back of an envelope, it’s rubbish" - Richard Branson
The solution is to deliver a prototypes based on refined business processes instead of a full specification document. Prototyping allows assumptions to be cleared and theories demonstrated, giving users and stakeholders a clearer view of what is to be achieved - decisions can be made with less debate and wasted time.
The benefits of building early rather than toiling over specifications are:
- decreased time to market by re-using proof of concept effort;
- faster Return on Investment (ROI) by delivering low-effort, high-priority functions first;
- reduced risk by clearing assumptions;
- the opportunity to fail early and recover before go-live.
Salesforce.com and Force.com allow you to build a solution in less time than it takes to document it. Add the availability of system metadata, and documentation can be created once an application has been developed.
A selection of our latest design documents are below, a coaster is about the same size as an envelope.
Self-document as you build and update your Salesforce instance.
The combination of the Force.com platform and ‘Drop my Dossier’ allows you to build first. Documentation is no longer a costly up-front overhead … or a forgotten after-thought. You can get on with prototyping - rather than developing and maintaining long specifications – and then deliver thorough documentation with one click!
Technology is moving too fast to fully document solutions up-front. Start building and get it done…. Welcome to #thecloudera.