How Melba came to understand scrum to make software development efficient.
Melba encountered many challenges before successfully establishing an effective software development.
By effective we mean:
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:
The team must also share the scrum philosophy and someone must have a positive experience of its application. This is the case with us as 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.
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.
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.
Because a sprint is exactly that: freezing the development team's to do to allow it to work in comfortable conditions, without interruption and without change of direction. The development 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:
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 be shared 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 doesn't.
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 their work must check off the various elements, which indicates that they have 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 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.
A second exchange is planned before the start of the sprint to allow the technical team to specify the technical to do. 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 to do on them or letting them flounder.
Example of a precise technical cut:
If the technical cut is not possible or is uncertain, then we won't be sure 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.
During the planning, the development team is accompanied by the PO who reviews the various tickets.
This planning is not a pain 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 capacity to do is estimated in points of complexity. This does not strictly correspond to available working time. However, we deduce from the theoretical suitable capacity to do and 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 capacity to do, 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 capacity to do 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:
If we do not know how to estimate the complexity, we timebox the time spent on the task. Example:
A timeboxed ticket :
At the end of a timebox, we have either:
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 capacity to do of the team.
The team took care of the following two points when defining the scope of the sprint.
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 capacity to do.
Example of a dependency graph between tickets in a sprint:
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 capacity to do of the team can answer it, otherwise we would take the risk of unknowns and would not keep it.
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:
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 they 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:
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!
Each time a ticket is finalized by a developer, the developer makes sure to respect:
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 their 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 :
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:
Reading The Gold Mine is very instructive on 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:
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.
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.
During the retro in particular, or at each daily, problems are raised.
Each of them goes through a troubleshooting procedure to prevent reoccurrence.
We borrowed from Théodo the following problem-solving framework with columns:
For 2 years, Melba tried the scrum without much success. We did not respect its spirit enough and we did not have prior expertise in the field.
This methodology is often disparaged:
From having tested the scrum that does not work then to the scrum that works, I think these remarks are obvious when we lack experience but that they are not correct in absolute terms: