At rtCamp, the software development process we follow is crucial for achieving success.
Building software the agile way
Without getting into jargon, let’s shine a light on one of the most modern methods we’ve adopted to build software: the agile methodology.
Back in the olden times (read 1990’s), both software developers and their clients thought they could get work done like car-makers. Developers would begin with a fixed set of requirements and shoot for completion, while clients would sit back and watch.
In the end, question marks would be left behind in clients’ minds: Was this something we really envisioned? Why not include something more? Or change certain parts?
The founding of agile
Developers would insist on sticking to early requirement lists even for lengthy projects to finish up quickly and move on to new projects. The process was anything but flexible, and would lead to intense debates about managing extended work.
To fix this, a band of developers got together at Snowbird, Utah, USA early 2001 and came up with their Manifesto for Agile Software Development.
To quote from the manifesto, the agile methodology means giving value to:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
“That is, while there is value in the items on the right, we value the items on the left more,” says the manifesto, referring to the above four points.
Agile has had its own detractors and may even be discouraged in certain contexts, but it has certainly brought about a sea change in the way many software projects are achieved.
Letting our code do the talking
We begin work only after gaining a decent understanding of our clients’ requirements, which we capture using cloud-based collaborative documentation tools.
The ultimate aim is working software delivered in well-defined phases – that’s the sole indicator of how we’re doing.
Coding up requirements is something we do in quick bursts, supported by short face-to-face meetups between developers.
What’s the key here? Quick bursts! That helps us learn fast and adjust our approach for newer development cycles.
All along, we make sure our clients are kept abreast of our progress, and leave sufficient room to accomodate changes that may be introduced during each work cycle. When we conclude that an added requirement is well out of the initially agreed scope, a suitable charge is decided.
In the end, when clients discover the full working software they wanted and come back to say ‘thank you’, we feel greatly indebted to the founders of agile for promoting a thoroughly success-oriented software development process.