Scrum framework is applicable in many kinds of projects and has multiple benefits but, when should Scrum be used and why? In this article we aim to illustrate an example of a project by bringing in a real-life situation and to explain why it could not have been done without an agile framework, in this case Scrum.
This client wanted to integrate a PWA frontend (Progressive Web Application) to their eCommerce platform. This was the first time that we would be integrating the two technologies together. Additionally, although this platform was working diligently in improving its PWA solution, it was still quite immature and many signs of warning were clear regarding the use of its APIs to solve complex functionalities that we had as requirements.
As we planned the project, the team identified various challenges which would be faced mainly because of this being a first time build. Firstly, we were set to use the eCommerce platform’s technological PWA framework, an avant-garde technology that is still in permanent change, which required understanding its capabilities and limitations, as well as the roadmap of future releases to be able to anticipate any upcoming features that we could need. Using a technological framework that is still under development and somewhat unstable was a second difficulty to keep an eye on. The fact that the technology is not stable yet demanded the Scrum team to be constantly making decisions regarding what component to use and which one to extend based on the needs, which was a third problem. Fourthly, the documentation was under development, which meant we could not trust it to be up to date and forced the team to enter a modality of real-time testing, making mistakes, and constantly adapting as well as trying different approaches. Fifthly, there was also uncertainty on the limitations of the eCommerce platform’s GraphQL APIs, partly because of the lack of documentation. Last but not least, we needed two versions in production to coexist: a traditional one and a PWA one using the same backend. Regarding this, we needed the technology to support multi store — multi country as well.
The situation was one of extreme uncertainty. The unknowns were great and the research we could do to understand them was limited by lack of documentation, immature technology, and ever evolving changes in the platform. However, we did understand the motivation behind the project, the pain the sponsor was trying to solve with a solution such as this one, and the economic impact of each day passed without having the solution live.
At this point it was clear that if we looked into a waterfall lifecycle approach (traditional methodology) for the execution we would lose valuable time researching and even then we would have not been able to confidently estimate the project. Additionally, choosing a traditional approach required having clear knowledge of how the final project looked like, which we did not have. On the other hand, an agile approach allowed short and strong pushes of progress, with constant measuring of how we were evolving.
The uncertainty described above was key to our process because the agile Scrum framework works best in uncertain contexts such as the one we were in. It gives the possibility to see the product evolution sprint by sprint and allows the client to realize, with the completion of each sprint, that the product has reached a stage in which it solves the main business problem and putting it live to start to see business value is now an option. This is one of the main advantages of Scrum, as the client sees the product evolving sprint by sprint, the system is being used. Therefore, the Product Owner can constantly evaluate if the product, in its current state, will solve the business needs. If it does, it can go into production while continuous improvements are developed and pushed live frequently. The double benefit that customers obtain with this model is typically overseen. If you decide to put a partial solution live because it has a positive economic impact in your business, you will benefit from early returns on the project while the tool is still under development. In a way, the project ends up paying for itself, at least partially. Instead, traditional methodologies, until the defined scope of work is reached, the client will have nothing to see regarding the progress of the project. This means a functional product may have achieved the project’s objectives during the development progress but it will not be done by the time needed.
We started with a Scrum team in which we had people with the necessary skills: we had React Developers and Backend Developers who trained in GraphQL because this technology requires expertise we did not have before. The construction of the prototype implied the challenge of learning and generating value at the same time. This is why this framework allowed the Scrum team to be in constant change sprint by sprint, always taking the goal of the sprint into account.
Scrum framework allowed us to face the challenges mentioned before in the following way. We paid attention to impediments in every daily meeting and we were fast in solving them or deriving them (by the Scrum Master). Because of this being a new technology, when something put the sprint’s goal at risk, the Product Owner always directed how we could take an alternative route that would not deviate us from the goal, he did not prioritize features that would not be necessary for an MVP (minimum viable product), or assumed consequences. Cancelling the sprint was not an option. The need for two versions in production to coexist really made it hard for the MVP to be viable since we could not use two different backends. Therefore, the team had to create a workaround that allowed this. The requirement of the technology to support multi store — multi country required redeveloping a significant piece of the platform, and we knew the feature would be included in a future release soon to come. Due to this, we decided that the MVP would be applicable in only one country until the feature became available from the eCommerce platform. We always asked ourselves: “Can we live without this being part of the MVP?” since it can be really easy to fall into wanting to do everything and doing it perfectly. Eliminating features that finally did not add value to the MVP was something the agile framework allowed doing, without so much stress as it would have been with a traditional methodology.
We realized, little by little, that many aspects were not required for the product to work, did not add value to the customer’s business, and that we could live without them. This is how we built the MVP, following the goal of each sprint until the MPV was ready for someone to buy online. This product could still be improved, but it was functional so that if someone visited the website, they could make a purchase. Through this process, we demonstrated in each sprint the product’s value, we made mistakes, we tested, we learnt, we made the product evolve and we were able to put a solution live that added significant value to the business in a short amount of time. This would not have worked with a traditional methodology.
In light of the above, the prototype’s objective was achieved allowing, in a maximum of 3 months, to demonstrate an improvement of 50% in page loading times in the app’s navigation in regard to a conventional frontend. As well, it is expected that when the application is 100% functional, we can present better conversion rates of 1 to 2 points. Without doubt the choice of working with an agile framework, in this case Scrum, was one of the key points for the success of the project. The possibility of experimenting, making mistakes, and learning as we saw the product evolve was perfect for the uncertain context we were in. As well, it allowed us to evaluate how to make the prototype progress by adding or eliminating features whether they added value to the customer’s business or not. When risky challenges approach, try Scrum.
We help clients grow their businesses by making creativity, flexibility, and talent converge into software development and UI/UX design. We are passionate and committed to take on challenges that can drive your business forward.
We combine our experience in Ecommerce, mobile, and web across various industries such as retail, wholesale, healthcare, government, and entertainment. This way, we work closely with you as a team in order to collaborate towards successful implementations.
.svg)