Most projects at Simplex follow Agile Methodologies.
This means we deliver software fast and deliver often.
This is different from traditional (waterfall) software development where you 1) plan the project once and then 2) the development team gets to work and 3) you’ll see the finished product at the end of production.
If you have a very clearly defined project scope and understand your market well, then this Fixed Scope project delivery may still be suitable.
However with the agile approach, if you are developing software from a new and untested idea then we generally recommend an agile approach that breaks your project down into small chunks (known as sprints).
This not only allows for more flexibility within the project, but also allows you to preview your new software rapidly (usually every 2 weeks) so that you can begin your market validation process ASAP.
How this works:
- Product Discovery Session to determine the overall product roadmap and product backlog.
- Prioritise which features will bring the most value initially, these features will be included in the first release of the project – known as the MVP (minimum viable product).
- Design & Development commences for the first iteration (sprint 1). Sprints generally last 2 weeks and are tight in scope to ensure the product can be delivered and the team commit to completing their assigned components.
- Generally the product is ready for review after sprint 1. The product is reviewed and sprint 2 is planned and feedback is taken into consideration.
- The sprint development and feedback cycle repeats
What if requirements change?
This is the beauty of the agile model. Agile development welcomes feedback during the development process and allows for changes of requirements and feedback new information comes to light.
By delivering software after every sprint (agile), you will be able to stress-test your assumptions about what you wanted and you may realise that you need to go in a different direction.
In this case, your new feedback can be implemented as early as the following sprint (only a handful of days away).
In comparison to waterfall, generally you are working with a fixed scope that is locked into a longer timeframe so that the feedback loops are generally way too slow to pivot.
Go to Market Quicker and Validate Sooner
At the end of the day, the software you are building is to serve some user base, whether it is internal or external. Before building, there is a set of assumptions you make about the problems that the product you are building is solving.
The quicker you can take that theory to market and validate whether it is meets the users needs or not, the better.
By focussing only on the most valuable aspects of your product first, you ensure that the time spent on development is not wasted on features that may or may not be used.
Say goodbye to long lead times and hello to rapid innovation.
Get in touch today to discuss your project.