Agile Feedback: The Morpheus Way
By Mehdi Boissat-Bron (Backend Developer)
Morpheus is a team that mainly develops internal systems for professional customers to enable them to post their classified ads on leboncoin and the other sites of the leboncoin group. And like most of the technical teams here, it has faced a transformation a few years back through the adoption of a culture of agility. This adoption took place in a more general plan of modernization of methods, technologies and processes so we would be able to continue producing a high quality platform even with a growing user base.
As a result Morpheus started to incorporate the principles of agility into the software development practice. These principles can be found in the agile manifesto and consist of 4 values and 12 principles. In order to apply these values and principles, different frameworks are available. At Morpheus, we decided to work with the Scrum agile framework. Scrum was originally a wrapper around extreme programming and then has evolved into a methodology on its own. It was adopted because it’s one of the agility layers offering the most structure and it was the methodology used by the other team as well.
In this article, we will see how Morpheus operates on a daily basis, with this agile method, now well implanted.
The life under agile scrum as a software developer
The scrum method allows more structure in the development cycle : when it used to be a continuous linear process, it now has short iterations for a period of 2 weeks. An iteration is called a sprint, the sprint is punctuated by a set of recurring meetings. Here you can find what a sprint schedule look like with the meetings :
First, the most common is the Daily Standup Meeting or DSM which is the shortest meeting, on average it’s 10 minutes (all other meetings are one hour or more) and takes place every day. Everyone explains what they are working on and if they are having difficulties. Then, on a weekly basis, there is the refinement of the Backlog, where future work that will be integrated into the next sprint is estimated. We estimate the difficulty of every future task with a vote system and eventually a discussion if there is no consensus on the vote.
At the end of each sprint we have 3 meetings : the Demo, when several teams of a similar functional scope regroup themselves to present key functionalities they developed during the sprint. Then the SPM for Sprint Planning Meeting takes place in two parts, a first where the product owner presents the different tickets that will be integrated into the next sprint and a second in which the developers divide the tickets into technical sub-tasks if necessary. And finally we have the Retro, which is very important, its objective is to determine what’s worked well or not during the iteration and to find future obstacles, all in the form of workshops.
Now that we saw what the schedule looks like, we can focus on five key points, to avoid an inconfort feeling from the project’s stakeholders.
Technical task are not on the side
It’s not uncommon to face a tension between product and technology, by pushing too much on the product side there is a serious risk of accumulation of technical debt. On the other hand, by making technology for the sake of technology, the result will be a delay in product advances. To restore the balance we have several practices.
The first is that leboncoin has several guilds. A guild is a community of people grouped together by common interests like backend, frontend, infrastructure and such. Each of these guilds has a guild event in the agenda, the backend guild for instance takes the form of presentations in the morning and workshop/discussion in the afternoon and takes place on Monday every 2 weeks (see planning image) And because this day allow to learn from others it help progress toward pure technical knowledge. The second point is to include technical projects in the roadmap which will allow a reflection on the long term needs of the software. And the last point is the integration of technical development in the sprint, which will allow short-term needs to be met.
Task estimation using points
In development, there are two main ways to estimate a task : by time or by points. Let’s take the following assignment “creation of a new endpoint of an already existing API”, an estimation using time would be for instance two days and therefore the person who will take this will have two days to complete the new functionality. This mode can be reassuring for the management but will create unnecessary pressure on the development team, forcing them to make shortcuts such as not writing tests or worse to go faster. The quality of deliverables will decline as well as the motivation of developers who will not have the chance to produce quality code.
At morpheus the alternative is use, this alternative is to estimate by points. Points are a representation of a degree of complexity. In our case we can have 1, 2, 3, 5, 8 or 13 points. Above that limit it’s necessary to split the task into smaller ones. For the assignment above the estimation could be two points, and so the developer who takes this, knows that there is a little complexity and therefore is assumed to be finished relatively quickly. Indeed even with points we still have time management in our mind. So it’s a win-win situation where there is still estimation but without psychological pressure during the process of development.
A set of rules around ticket management
Tickets are used to complete a task. A ticket is most often written by the product owner but also by the developers themselves or the other stakeholders on the project. As this is an essential working tool, it is important that they are well written to avoid unnecessary waste of time. To illustrate this, if a bug is reported, the ticket must contain at least a clear title, the steps to reproduce the bug, the actual result (preferably with a screenshot) and the expected result. In addition to avoiding wasted time, it also provides clear documentation on the why and how of the changes that have been made. This is particularly useful for new members who join the project.
The importance of the scrum master
The role is to guarantee the proper functioning of the sprints. This can be a full time job and in this case, the person will take care of several teams. Or it can be an additional mission of a team member. At leboncoin it’s usually an additional mission. The scrum master, for instance, ensures that the daily standup meeting does not exceed the timebox, is also organises the sprint retrospective which is the most important meeting in the routine, and is indeed going to prepare workshops in advance for this. Another assignment is to make sure that no additional tickets are integrated into the sprint and the initial contract is respected. And finally there is also a privileged link with the product owner in order to transmit any problem related to the sprint.
An approach to deal with emergency
Tasks based on points, presence of technical development, well-written tickets, the presence of a scrum master, all of this allow quality work to be accomplished. But despite all this, there will unfortunately always be bugs in production or requests for important features to be made urgently which can disrupt the proper functioning of the sprint. To prevent this from happening we designate a person in the team who will deal with all these urgent developments for a defined period of time. At leboncoin a popular way to call this role is the fireman. A week for this role as it’s a good period of time.
After all, the current methodology provides good results but since agility is a synonym of flexibility, we occasionally try new practices or remove elements if they do not work. In any case I hope this gave you some inspiration to enhance your own work methodology.
