The SCRUM methodology

February 2014, 9:02am the phone is ringing. A customer tells me that he is very surprised, because the site we delivered to him the day before does not correspond at all to what he imagined. I look at the specifications with him, and realize that what seemed obvious to us a month ago is much more ambiguous today. We, who thought we had completed a site, after a trying period of development, are starting again at 0...

And then we met SCRUM.

Let's start from the beginning

We developed our first crowdfunding platforms with the Waterfall methodology, which is extremely classical in project management. We had predefined specifications that we reworked to best meet the expectations of our customers and a delivery date. We then proceeded to develop the platform. Then, after a recipe phase, we put it online.

But very quickly, we were confronted with the following problems:

• Of incomplete specifications, which blocked the developer or forced him to make choices about the platform,
• Of Significant tunnel effects during the development phase with an absence of interactions between the development team and the client, which was all the more detrimental as we were responsible for developing innovative solutions requiring the client to be involved in strategic development choices,
• Of recipe phases which took an enormous amount of time to collect all customer feedback and significant developments to be rescheduled. We realized that many changes would have been much easier to implement before,
• One Unmanageable schedule : it was impossible to reconcile our new developments with revenue phases of unpredictable durations.

We realized that while the Waterfall methodology worked well for standardized products, on the other hand, it was not at all suitable for the innovative solutions we were developing. These applications require the continuous and sustained involvement of the customer so that they can decide on major directions and major changes in the development of their platform.

To avoid reproducing these mistakes, we decided to:

• To standardize the identical functionalities on our platforms as much as possible,
• And to adopt the SCRUM method for tailor-made developments so that each new platform can bring its share of innovative functionalities.

Why SCRUM?

SCRUM is the best of the existing agile methods because it is the only one that involves the customer in an intelligent way by regularly soliciting him as a decision-maker on all the functionalities to be deployed and on the major pivots that may be necessary during the implementation of the project.

In addition to that, it is an extremely productive method since it optimizes the time of the customer and developers. Thanks to daily project reviews by the customer, developers know exactly what tasks to do, how to do them, and how quickly to do them. From the very first projects, we felt that this method had given a boost to our productivity and to our organization.

What is important about the SCRUM methodology?

Adopting a methodology is not everything; it is still necessary to understand it. Before implementing it, we identified the main risks of the SCRUM methodology.

For the Product Owner

At the heart of this methodology is the Product Owner. His role is critical because he is the one who will plan the sprint by expressing his needs and defining his priorities.

In addition, it is he who will define the concept of work accomplished by validating the tasks of the development team. If our customers are demanding with us, we are also very demanding of them so that they are the best Product Owners and are 200% involved in their project.

For the development team

During the ceremonies, the main function of the development team is to translate and technically think about customer expectations. During sprint planning, she actively participates in building the architecture of the platform while ensuring that the tasks given to her are well defined, feasible and that their duration of completion is fair.

At the time of the sprint review, the development team:

• Details to the customer his latest achievements in order to bring together the client's desires with the work done,
• And explains to him the potential technical difficulties she may have encountered while offering a solution to overcome them.

The development team must know how to express a technical need, and its necessity to the product owner. We had to set up collaborative tools (Slack and Trello) to facilitate communication between the product owner and the development team. “Pedagogy is the art of repetition” some would say.

For the SCRUM Master

The SCRUM Master, for its part, is the guarantor of the correct deployment of the methodology. In concrete terms, he ensures that all project stakeholders know their role and ensures that the client's expectations are in line with the abilities of the developers. He can make concessions on the principles of the methodology only when this makes it possible to better involve the customer.

In addition, he hosts the sprint retrospective, a ceremony during which the SCRUM team introspects and seeks to improve for the next sprint.

The benefits of the SCRUM methodology

Meeting SCRUM allowed us to have:

• ‍Achievement comfort for the team of development since the team participates in the specification of tasks and in the estimation of their completion time. This makes it possible to be more attractive in terms of recruitment.‍
• More frequent monitoring of projects and rigorous that minimizes the risk of major delays,‍
• A fruitful relationship between the client and the team development, which increases the business understanding of our developers and the technical understanding of our customers,‍
• Much happier customers of their product because they are regularly involved in decisions. The acceptance phase is no longer long and complicated, but fast and carried out over time, which allows the customer to correct the situation as soon as the design of the latter begins to deviate from his expectations.

Today, we are no longer a simple technical performer but we have an important role in the design of the project as well as in the pivots to be carried out. We are the ones who optimize with the customer both their product and the experience of their future users.

Respect the Scrum methodology

What we learned from the SCRUM methodology:

• ‍It must be respected to the letter to benefit from its numerous advantages because it is its constraints that make it so effective.
• But there is a unique case where we think that You can do a sprain to the methodology: when the customer is not sufficiently involved in the development process because he is not receptive to the methodology, you must know how to model it at the margin so that the product owner remains at the center of the project.