On Tuesday 13 July, we released version 3.45 of our solution with a dozen new features!
But in fact, why do we organize these releases? Why a 3 week delay? What does this mean? How does it work?
- allowing the team to focus on a realistic, short-term goal;
- Allowing to organise and structure these developments;
- Allowing better communication on deadlines to customers as the sprint becomes the unit of time;
- Allowing to manage any unforeseen development because the delay is managed not on a day-to-day basis but on a sprint scale.
Our solution being in SAAS and used by more than 180 customers and more than 3M end members, it is important to limit regressions, and therefore to structure developments to do these non-regression tests. Obviously, critical or blocking bugs escape this sprint-based approach and are the only corrections that are put into production and deployed continuously.
These user stories are written by the project managers in a ticketing tool, “redmine” in our case, which allows them to be organised and assigned in a simple way. The client also has access to “redmine” for the sake of transparency.
The task of the product owner with the planner (our CTO in this case) is therefore to prioritise them and place these “user stories” in a sprint.
A sprint is therefore a set of tickets.
PRESENTATION MEETING
The sprint therefore begins with a first scoping meeting with the whole team (PO, PM, Dev, CMO, UX designer, etc.) which allows the various tickets to be presented, of which there are usually 60-80.
This allows the tickets to be distributed among the developers, and to specify the specification needs which will allow the modelers and analysts (design/BDD/UX designer) to write the specifications in a first phase, and to have them validated by the PMs or clients.
TESTS
The second phase then tests the tickets and delivers them to a development environment, either internally or externally.
VALIDATION
At the ⅔ of the sprint, during our Friday breakfasts (“friday breakfast”) the project managers present the different developments. The idea is to begin to better understand the developments made but also to test their understanding, their usability, and discuss any options (are they activated by default, what value, what interest?).
When we develop more than 150 features per year, the essential point is that they must all be understandable by our customers. Otherwise, we might as well not communicate on them 😉
We are therefore starting to see which tickets we are going to communicate about and which ones will be passed over in silence, either because they are too technical or because they are not interesting enough for the customers.
COMMUNICATION
During a final meeting at the end of the sprint, the developments that will indeed be deployed are validated (some may be arbitrated because they have not been completed and handed over to the next sprint) and a decision is taken on which developments will be presented at the release and the order in which they will be presented. The CMO then writes the documentation added in administration and prepares the Newsletter sent to the customer.
DEPLOYMENT
On the morning of the release, during the daily sprint we validate the last adjustments if needed, and at the end of the morning we launch the creation of the development branch that will be deployed in production. The cutover on the sites takes less than 5 seconds and allows the switchover of a version to be almost transparent.
SPRINT REVIEW
That evening the team does a sprint review. Concerns, misunderstandings, mistakes to avoid or improvements to capitalize on or lessons for the future sprint.
And the next morning, we talk about ….. the next sprint!
WHY 3 WEEKS ?
We are often asked this question. What is essential to meet customer needs is to have a short development cycle. This avoids regressions, makes it easier to distribute developments (the longer the sprint, the more expensive it is to shift a development to the next sprint) and does not limit technological leaps and, above all, smoothes out new features.
It’s obviously easier to work on a number of weeks because that’s the classic way of organising work, but obviously one sprint per week is much too short because it doesn’t allow you to organise yourself.
We tested two-week sprints for two months, but we quickly stopped because on the one hand it exhausts the teams, who have the impression that they’re doing one sprint after another, and on the other hand it doesn’t allow them to focus on complex functionalities, which are therefore seen too quickly. We also have to integrate a possible validation phase with our clients, who may not be available and able to be mobilised during the week.
We have therefore been working in 3-week sprints for more than two years now and we are convinced that this is the right pace. Shorter is unmanageable, longer is useless!
AND WHY TUESDAY?
As a matter of principle, we exclude releasing a new site or a release on the Friday before the weekend… As a release can be postponed to the next day due to an unforeseen event (this happened to us once in 43 releases!) we avoid releasing it on Thursday because the delay would make Friday fall…
Moreover, Monday is a little early in the week because we may need to coordinate before the release or communicate with customers.
That left Tuesday and Wednesday. But since Wednesday is usually taken for people in ⅘, that meant we had fewer clients present when the release went out, so we moved to Tuesday!
And it works well with the Friday before when we do our “friday breakfast” and thus allows us to prepare the communication about the release over the last 3 days.
REVIEW ?
The implementation in 3-week sprints had followed a team seminar with the developers.
For the team and our clients, the 3-week sprint approach solved many problems:
- respecting the schedule: we no longer need to reorganise the schedule on a daily or weekly basis since the time unit is the sprint
- decrease in stress: since the goals are shared in the team, it decreases misunderstandings and stress because a task is not completed.
- no more regressions: as development environments are realigned with production at the beginning of the sprint, and unit and integration tests are produced on time, we no longer have regressions when moving into production
- better customer communication: customers know precisely what the deadlines are (previously we had trouble getting an exact date for release which created stress and customer misunderstanding) for delivery
The only constraint is that in principle a sprint in progress should not receive any more new developments. This is a concern because it means that a new customer request can not be processed before the next sprint, that is to say between 3 weeks (if the sprint has just ended) and 6 weeks (if the sprint started the day before). This was obviously painful to set up at the beginning (and sometimes still is now ;-), but the clients have now understood the interest of this operation, and are perfectly satisfied. Indeed, it is better to have a precise and more distant date than a date that is close by and that is postponed… The counterpart of this organisation is that we can commit to deadlines and to a better mutualisation of developments.
ANY QUESTION ?
