There are two types of app development methods that you will hear most frequently discussed – waterfall and agile. Waterfall in essence, is a traditional method where you complete each item in a pre-determined sequence. Agile on the other hand, uses an iterative approach, working in shorter bursts and refining with each stage. To understand this quickly, refer to the pros and cons listed below.
Early software development used the waterfall model to define a project lifecycle. Typically, the development team would take a long time to write a massive requirements document, go away for several months to write code, and then provide a fully completed product to their clients. This wasn’t a good approach and the delivered product often failed to meet expectations.
The first part of the waterfall model isn’t bad, and most modern development teams will start the development process by gathering requirements. If you’re going to need a fixed price quote for development, then the scope must be fixed also, as we discuss in the topic how much should I pay? Even if you have a time and materials contract, and we all agree and understand that requirements are going to evolve during development, we still need a URD that tells us what to start building before we pick up our tools.
The second part of the waterfall model isn’t bad either, and most projects go from requirements gathering and documentation into design. It is the next part, implementation where modern development practices diverge radically from the historical path, and this is where agile methodologies come into play.
Agile takes lessons learned in the automotive industry about empowering workers to make decisions, and providing much faster feedback of results. At Dapper Apps, we are massive enthusiasts of a popular flavour of Agile development known as scrum. Like other Agile methodologies, Scrum solves the problem of producing a large product with vagaries in requirements by introducing continuous delivery via a sprint cycle, with project updates (actual apps) being provided at the end of each sprint for clients and stakeholders to see how the project is unfolding, and provide feedback along the way.
The sprint itself is highly structured. Every two weeks there is a squad of developers and quality assurance engineers (QA’s) working on a project, coordinated internally by a squad master, with the following specific events taking place:
- Sprint planning.
The squad spends up to a day talking with the client, account manager, and among themselves to prioritise and plan the work they will undertake in the following two week sprint.
- Daily stand-up.
The squad conducts a daily stand-up meeting (no sitting!) every day during the sprint in which they discuss in turn what they worked on yesterday, what they are going to work on today, and what (if any) impediments are affecting their work. Large discussions are flagged and taken outside the meeting, so a typical stand-up meeting lasts just 10-15 minutes.
- Sprint retrospective.
At the end of every sprint, the developers meet to discuss how they performed during the sprint, highlighting things they did well and things they need to improve on.
- Sprint review.
The sprint review typically happens after the retrospective, but we find it more beneficial to provide apps on the Friday and allow people to review these themselves over the weekend or on Monday, and then include the sprint review at the start of the sprint planning meeting. This meeting should involve the squad, account managers, and client, and is used to discuss project deliverables.
There is a lot to like about Scrum, and it has proven success in our industry. Development teams like to be empowered by the process, and the simple events mandated by the process mean there is a good balance between getting work done and keeping everyone informed of progress. Project managers like scrum too, because it breaks projects into manageable chunks and they don’t have to resort to Gantt charts and other ineffective methods to forecast how a large multi-stage interdependent project might unfold. Scrum is effective in keeping clients involved and engaged, with regular reporting periods and deliverables, and we receive glowing reports of these methods.
There is a lot more that can be said about Agile and Scrum methodologies. The links earlier in this document provide a more thorough explanation of some concepts, and there are many other great resources online if you’re interested in this topic. For now, we move onto discussing our methods of communication and transparency, and how this all comes together in the section what to expect.