Are your requirements stable and understood in its entirety? Are you sure about your technology and is it mature? Are you sure you are not going to take on anything unknown during the development process.
In today's fast changing world, in all probability, the answer to most of the questions above is a No, implying that traditional heavy (as opposed to lean) methodologies such as Waterfall model would not meet the goals. What is needed is a lean methodology wherein requirements analysis, design, coding and testing all can happen in parallel in small chunks thereby producing a usable product after every cycle.
The Agile Way
At QAIT DevLabs, we follow Agile development methodologies in all our software engineering efforts. We have adapted our agile practices in a way that best suits building products from scratch as well re-building or sustaining existing software products. Read further to know how our practices bring into play the below principles from the Agile Manifesto.
Implementing Agile Manifesto
"Satisfy the customer through early and continuous delivery of valuable Software. Deliver working Software frequently, from a couple of weeks to a couple of months, with a preference for the shorter timescale"
Every project starts with a master planning that determines high level features for the product, best estimates and mapping/splitting them into small releasable chunks. These chunks are short development/QA efforts labeled as a Sprint. Typically we prefer a 2 week Sprint schedule. Every Sprint starts with a planning meeting that outlines a clear path to achieve the deliverables over the duration of the Sprint. Meticulous planning taking into account backlogs, and expecting unknowns along with daily tracking ensures that we never deviate from the plan.
"Working software is the primary measure of progress"
The client is provided with a staging environment where, every 2 weeks, a usable product is delivered. Thorough review by business users of the actual delivered software every 2 weeks ensures that we are building the right product.
"Business people and developers work together daily throughout the project"
We follow a SCRUM model wherein teams carry out daily stand up calls discussing progress and impediments, if any. We insist representation from client's business users and product owners in these meetings. Daily forced communication between people at the client's end who understand what to build and our team minimizes the risk of deviation. Such regular discussions also fosters creativity in terms of coming up with new ways of building the features.
"Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage"
The best products get built not by conceptualizing the right features at the beginning, but by responding to real users of the product and adapting the features as per their needs. How fast one can do this determines one's competitive advantage in the market. We understand that. We change plans/priorities fast and remain extremely responsive to client change requests.
"Continuous attention to technical excellence and good design enhances agility"
We are proud to have a great engineering team who practice excellence. Every feature undergoes a thorough three level review - design/architectural review, detailed code review and functionality check as part of the development process (independent testing is carried out additionally). These reviews ensure that all functional and non-functional needs are taken into consideration while the code is written.
"Simplicity -- the art of maximizing the amount of work not done -- is essential"
We strongly believe in keeping things simple. Often cases there are multiple ways of developing a feature, our recommendation is always to use simple yet effective ways. This reduces the code complexity and makes the product maintainable. Similarly, simplicity applied to user experience engineering results in software that is more intuitive and usable.
Strong focus on Testing and Requirements
Our adaptation of agile puts a strong focus on testing. However, managing testing in such a fast moving and fast changing development environment is challenging. Hence, we take a phase lag approach wherein the test cycles lag a phase/Sprint behind the development cycles. What gets built in Sprint N gets tested in Sprint N+1. Similarly a thorough analysis of requirements for features to be built in Sprint N along with detailed test case writing is carried out a phase before in Sprint N-1. The end result yet remains the same, that every 2 weeks, a usable product is released to the customer.