In 2008, I began work with a client on a new project. The client was a airline and travel agency that needed to rewrite, from scratch, their online travel booking application. The new website had the following primary requirements:
- Improve end user experience, including performance and security issues;
- Offer new set of products on the website (Hotel booking, car hiring and insurance purchase); and
- The new application had to connect to a brand new back-end system.
After learning about their process and project, I suggested that we try a new approach: Scrum. My clients did not know much about Scrum. In fact, the only Scrum-like practice my client had tried was daily meetings. I insisted that using Scrum could help us build software more quickly and build it with higher quality. This was not easy to sell. The client had a number of questions, such as:
- How can you accurately estimate a project with an iterative process?
- How can you determine the delivery date of a project if you re-estimate it after every sprint?
- How can your customer agree on an analysis and “sign it” if you do not have an analysis phase?
- Isn’t Scrum just a cowboy development process since we do not have a detailed design phase?
I answered their questions or worked with them to find answers. At the same time, I did not pretend that Scrum could solve all of their problems. I did point out what they already knew: their existing waterfall methodology, with its detailed estimates and phases, only gave the illusion that it could deliver a high quality product with all required features on budget and on time. Scrum, on the other hand, could mitigate some of these risks. After much debate, we decided to give Scrum a try.