By Gustav Coleske – Mendix Consultant & Lead Scrum Master.
We are increasingly delivering projects that are based on the agile approach for our clients who have traditionally run projects that used the Waterfall approach. We delivered our projects by using Mendix which is a digital transformation company that has developed a platform as a service product for rapid application development. This cloud-based platform allows users to build, integrate and deploy web and mobile applications very quickly. These applications can be built either from the ground up or as a layer on top of existing legacy systems (see https://en.wikipedia.org/wiki/Mendix). We have noticed common themes throughout these projects that a Waterfall approach won’t handle very well. We want to share some of the common things we have come across relating to the adoption of the agile approach over the traditional Waterfall approach.
If you are new to application development, or do not understand the approaches that can be used, or find the whole thing a mystery you can find excellent information on the web. For a very quick and high level overview of which methodology to use see the diagrams below. From my experience it’s the application that you are developing that should dictate the approach or methodology you should adopt and not try to fit a square peg in a round hole.
If your project is very structured, such as a payroll system, it will be relatively static (changes are infrequent), with a clearly defined output against a clear set of rules. Or if there is little need for interaction between the developer and client team, then Waterfall is a good option.
Agile does not require the exact design to be completed before development starts. The premise is that you know what the application should do but work out how it should operate as you go. This is achieved through short and productive development with playback and then incorporating changes quickly – seeing is believing after all. One recent project I was lucky to work on included functionality that was not thought of at the beginning of the project, but we were able to incorporate it in the agreed project timelines.
Identifying The Product Owner & Key Users:
Identifying your product owner and typical users is critical. As with the waterfall approach getting the commitment from team members is critical. However this is even more so with agile due to the short development and testing cycles.
The business owner needs to commit time to attend daily scrum meetings as well as sprint planning and sprint demo sessions. The Product owner is the gatekeeper for the project and will be the contact for stakeholders, with decision-making power during the implementation, will respond to queries of the development team and will ensure the value of the work being done.
Whoever is identified as the product owner, will need to have capacity and accountability to assist with this.
Key users will assist in delivering the user stories and input for the development process. Once the user stories are developed, the key users will test and accept functionality based on these stories.
If there are issues with existing functionality or new ideas come to mind while testing, the key users will be raising the relevant feedback items.
As with any project, not getting the commitment from the relevant product owner and key users or changing these stakeholders midway through a project is recipe for failure.
How about you? If you’ve tried agile development let us know your thoughts. Or if you’ve only experienced waterfall how come? Just leave a comment below.
If you would like to discuss the projects undertaken by our clients please get in touch. Alternatively, download our free e-book on how digital applications can drive business performance.