Effective scrum: melba does sprints and that works well

Comment melba a réussi à comprendre le scrum pour rendre le développement logiciel efficace

Published on 04/28/2021Sébastien Vassaux

Melba a rencontré de nombreuses difficultés avant de parvenir à mettre en place un processus de développement logiciel efficace.

By effective we mean:

  • Work on the right topics
  • Make predictable the result to be obtained after a given period
  • Have a suitable capacity to do (CAF)
  • Put into production regularly
  • Do not have a regression during production releases
  • Iterate by increasing our CAF
  • Satisfy the development team and the entire company

Prerequisite

Before trying to organize the work of a development team effectively, it is important to determine a coherent scope of work. We have achieved this through the implementation of a  quality product process.

This assumes that we have succeeded in determining precisely the next functional priorities:

  • these priorities stem from the expression of the need expressed by users and from strategic initiatives that serve our vision
  • they are accurate - the work of UX and UI has removed doubts that the solution meets the need

The team must also share the scrum philosophy   and a first person must have a positive experience of its application. This is the case with us, one of our  lead developers  practiced it ardently.

We were also able to realize our early mistakes when reading  Scrum in Action  by Guillaume Bodet. The book describes a rocker that we have experienced, from working in a V-cycle to applying scrum. A contract with a large group had given rise to the drafting of voluminous specifications. The need was not clear to anyone, changed frequently and the demands of our partner and our desire to comply with them led us to sacrifice quality: we had fallen into a vicious circle where urgency pushed us to botch and put in production every 3 months to realize many regressions and a mismatch with user needs.

Scrum is a communication tool. Scrum enables teams to synchronize effectively, work on things that matter, and reap the benefits quickly. To be anti-scrum is not to want to communicate effectively.

There are several cases of scrum allergy   :

  • a first unhappy experience which assimilates the method to a religion punctuated by useless ceremonies. What is the use of doing a stand-up and repeating for the 5th time of the week the subject which concerns us from the beginning? You have to realize that the problem is working on the same subject for 5 days.
  • an aversion to process that can arise from the fear of being coped: “let me do it”. It does not apologize, processes enable scaler team, in all departments.

Today melba puts very small tasks into production 2 to 5 times a day without regression. Our users give us feedback every day that we are able to process quickly.

Preparing for sprints

We chose to work on short sprints: 1 week.

This increases the  overhead  but decreases the preparation work and allows you to be more agile. We could adapt the slider and choose to reduce the overhead  by increasing the risk associated with setting a larger functional perimeter. Risk:

  • that the tickets lack preparation
  • as the need changes
  • that external elements disturb the sprint (bug to be solved urgently...)

Because a sprint is exactly that: freezing the   development team's todo to allow it to work in comfortable conditions, without interruption and without change of direction. The dev team knows what to do for the next week and no one is going to bother them.

The sprint is made up of  user stories  (US).

Before going into detail, here is a Trello card  representative of a US below  . Its content is described in the following paragraphs.

Example of a complete US:

An explicit and documented user story

A US takes the following format:

As <persona>, when I am in <context>, I want <action / result>

We also define the  Why  : why is it important, what is the user's need.

Finally, we add a link to a model and other resources that may be necessary (font, pictogram, image, etc.) in order to limit the research time of the development team.

We link the US to our wiki which summarizes all the acceptance tests as well as to our static API documentation. This static API documentation, modeled after that of  Stripe , is to backend development   what mockups are to frontend development  .

Each US can be put into production. If it is part of a course whose minimum set is not yet ready to share with users, it is nevertheless put into production and hidden.

Note: we sometimes make the difference between  user story  and  job story.  Melba instead does  job stories  that include context, while  user stories  traditionally don't.

Acceptance tests

Acceptance tests include the business logic elements that the functionality must satisfy. It is interesting to divide the US into small-scale elements so as not to impose too complex a logic and thus more easily identify  edge cases .

Acceptance tests make it easy to see the result: the developer who finishes his work must check off the various elements, which indicates that he has verified that the expected result is obtained. If expected behaviors are not listed in these acceptance tests, the PO must create a new ticket.

The  refinement backlog

The refinement backlog is an opportunity for the PO, the UX and members of the development team to go through all the tickets anticipated for the next sprint (or even a little more) in order to eliminate misunderstandings, inaccuracies, risks, etc.

Workshops and presentations of design work upstream of the  refinement backlog  make it possible to sensitize the technical team to functional issues, but during the cutting we enter a level of refinement that makes this exchange necessary. The business knowledge of UX and PO is shared and the technical team helps to make trade-offs that go in the direction of a better ROI. 

Technical cutting

A second exchange is planned before the start of the sprint to allow the technical team to specify the   technical todo . On this occasion, each functional task is technically broken down.

The challenge is to remove all points of doubt so that there is no unknown during development. Thus, we go so far as to name certain classes and methods and explain what will be done and how, collectively, between developers. This is an opportunity for seniors to pass on their experience to the juniors rather than just imposing a   misunderstood todo on them or letting them flounder.

Example of a precise technical cut

If the technical cut is not possible or is uncertain, then we will not be sure to know how to assess the complexity of the task and we will have to  timebox  the time spent on it to avoid getting too lost. We will come back to that.

The  schedule sprint

During the planning, the development team accompanied by the PO reviews the various tickets.

This planning is not a suffering as it could have been in the past when the team discovered needs incompatible with its capacity to make or still conceal enormous unknowns. The upstream collaboration has borne fruit.

The  planning poker

The capacity to do is estimated in points of complexity. This does not strictly correspond to available working time. However, we deduce from the theoretical CAF the time taken by events not associated with development (meetings, interviews, etc.). On this occasion only, we make the amalgamation between complexity and working time.

In particular, we deduct from the total CAF the time dedicated to the  refinement backlog , technical breakdown and  sprint planning . This provides an incentive to make these meetings effective and removes the risk that these meetings may get long.

To estimate the complexity, we use an agile card game and we rely on benchmark tickets. We note each ticket and the sum of the notes of the tickets to be made must be close to the CAF of the team whose measure is refined sprint after sprint.

Each team member independently estimates the complexity of the tasks and presents the team with a card from the Agile game with a number on it. If there is no consensus on this estimate, extremes are expressed until consensus is reached.

This only works if the following elements are respected:

  • the US is clear
  • the technical team has read it
  • the task is technically cut
  • the complexity is low <5 which is equivalent if we allow ourselves a conversion to a working day

If we do not know how to estimate the complexity, we  timebox  the time spent on the task. Example:

timeboxed ticket  :

At the end of a timebox, we have either:

  • finished the ticket: bravo!
  • solved the technical uncertainty: we create a new ticket that follows the same formalism
  • failed: the timebox made it possible to avoid spending too much time on a subject with improbable results. As a result, a junior asks a senior for help, a senior addresses a colleague or challenges the ROI of the ticket and opens a discussion with the PO.

During  poker planning , the team takes the tickets from the  product backlog  that have been prioritized by decreasing importance and estimates them in turn. The team stops estimating the tickets of the  product backlog  when the sum of the complexity points of the tickets inserted in the  sprint backlog  exceeds the average CAF of the team.

The team took care of the following two points when defining the scope of the sprint.

The dependency graph

A ticket dependency graph is produced which allows you to define in which order to perform the tickets.

The dependencies are such that the team theoretically cannot be blocked. If one feature blocks all the others, the sprint perimeter is modified to give the team leeway on parallel tasks and make the best use of its CAF.

Example of a dependency graph between tickets in a sprint:

The  sprint goal

Once all the tickets have been evaluated and the scope of the sprint fixed, we define a  sprint goal .

The  sprint goal  encompasses several tickets and constitutes the priority of the development team, it is a macro-US, an epic or even a complete course. This is the priority of the global sprint.

It must be elementary enough so that less than 50% of the CAF of the team can answer it, otherwise we would take the risk of unknowns and we would not keep it.

Example of two  sprint goals  reached by the team:

During the sprint

The  daily stand-up

What has been done: the  burndown chart

In the morning, the PO brings together the development team and everyone expresses themselves on what has been done. The dependency graph is used and completed tickets are crossed out.

The  burndown chart  is re-edited and lets you know where the team stands in relation to its sprint goal:

  • Are we early / late?
  • Has a problem occurred?
  • How to solve the problem ?

The rest of the things to do

Each member of the team then decides on what to do. The choice is free within the limits of what is imposed by the  sprint backlog  and the dependency graph, with priority placed on the sprint goal tickets  .

Each member also chooses tickets that he will be able to complete during the day. We try not to drag a ticket from one day to another which would induce undesirable effects:

  • inability to test and validate at the end of the day
  • daily stand-up  less relevant because work in progress
  • initiation of a drift leading to no longer favoring the completion of tasks

Daily email

A recap is sent to the entire team to keep abreast of the progress. As CEO, this recap is extremely appreciated. It is quality reporting that allows me to understand if there are any problems and to react accordingly. It is also a great decision support tool for the PO!

Example of  daily email:

Example of another email that addresses a problem resolution

Validation and production

Each time a ticket is finalized by a developer, the developer makes sure to respect:

  • acceptance tests
  • The  definition of done
  • good development practices, in particular rules related to  git flow

In addition to the acceptance tests already presented, the  definition of done  brings together elements of general value.

The developer pulls a  feature branch  thanks to  now , a tool from  Zeit.co

He performs a PR and verifies compliance with the following rules:

All you have to do is get a positive review, be up to date with your master 's  degree  and pass the tests on our CI tool,  CircleCI (now Github Actions):

The developer then shares the address of the  feature branch  on his ticket, a slack notification   is sent to the PO who tests. If the test is positive, the PR is merged and the feature goes directly into production 🙂

At melba, a  push  on  github  launches the tests with  CircleCI  :

  • unit tests on the front with  jest , on the back with  phpUnit
  • functional tests with  cypress  on the front and  behat  on the back
  • AirBnb linter tests   on the front and a custom linter on the back

The application is deployed on a cloud server via an ansible script   and   the  SPA build  is done by  webpack  on a server hosted by  Zeit.co.

Releasing very frequently assumes that:

  • tickets and PRs are small
  • the reading of PR is given priority before the advance of another ticket
  • the  build  and  deploy process  is automated

Reading  The Gold Mine  is very instructive to hear the interest of this process: all the added value of the team, at every stage of the development cycle in the broad sense (from  sourcing  to corrections in production ), is pulled as far as possible towards the end user. We keep a minimum stock of added value at the different stages of development:

  • we define priorities with a calculation of ROI aligned with our strategic initiatives (see  our article on lean )
  • we minimize the tickets whose  specs  are ready (the added value of our PO lies elsewhere)
  • we do short sprints
  • we advance on the tasks in priority 4
  • we read the PR in priority 3
  • we put in production in priority 2
  • we fix the bugs in priority 1

Retro

Yay! the sprint goal has been reached and the sprint is over!

There are two goals in a sprint: the sprint goal and the completion of all sprint tasks. The sprint goal makes it possible to secure a less ambitious objective and to ensure that a gain is however acquired at the end of each sprint.

The demo

We demonstrate new features either in front of the whole team or during the feedback that precedes the schedule (to reduce the  overhead  due to meetings)

The demo is useful for synchronizing with team members who are not part of the product development process and contributes to the satisfaction of the development team members.

Problem solving

During the  retro  in particular, or at each  daily , problems are raised.

Example:

  • a US is not well drafted
  • we started a sprint containing tickets with outdated dependencies (API not ready)
  • we started a long ticket at the end of the day and the work could not be validated

Each of them goes through a troubleshooting procedure to prevent reoccurrence.

We borrowed from  Théodo  the following problem-solving framework with columns:

  • Date and owner
  • Problem encountered and quantified impact (1 problem max per person per day)
  • Root cause (5 Why methodology)
  • Action that corrects the identified cause and prevents it from recurring
  • Date of action (ideally the same day)
  • Expected result
  • Scheduled check date
  • Observed result
  • Status (problem identified, action proposed when the problem is encountered, action challenged by the team at the next daily, problem resolved)

Conclusion

For 2 years, melba tried the  scrum  without much success. We did not respect his spirit enough and we did not have prior expertise in the field.

This methodology is often disparaged:

  • too stiff
  • stand-up unnecessary
  • no sensitivity to technical debt resolution
  • atomic work unsuitable for architectural work
  • coping
  • ...

For having tested the  scrum  that does not work then the  scrum  that works, I think these remarks are obvious when we lack experience but that they are not correct in absolute terms:

  • the supposed rigidity becomes comfort as soon as the process turns on its own. What satisfaction to be able to know in advance what will be done and to see week after week that the objectives have been achieved! In addition, we can exceptionally allow entry-exit tickets to the extent that they do not substantially change the sprint.
  • the stand-up is effectively useless if we work for a week on the same ticket and we are not helped by the  burndown chart  and the dependency graph. With these tools, we are succinct and we take action. We cross out the completed ticket and only talk about the problems if they exist.
  • technical debt can be included in sprints. We do this regularly at melba. The lack of sensitivity to technical debt puts the company at risk, it becomes a business issue as well.
  • the development team is responsible for properly architecting the applications and sprint tasks can be dedicated to architectural work. These tasks can also be timeboxed; at the end of the timebox, we report it to the rest of the team who decides to allocate more time to it depending on the resolution of the uncertainty. There may be more time allocated to R&D and in this case the dedicated CAF may be removed from the sprint as is the case for anything that takes time (meetings, interviews, etc.)
  • the scrum methodology makes it possible to constantly know the progress of the development team, in particular by guaranteeing high quality communication. Is it better to have an opaque system that lowers trust or complete transparency that leads to many small successes?

Photo © Christopher Gower on Unsplash