How we do agile in fraud prevention at cabify

Today, ways of working or practices are basically mirrored from one company to another without thinking about it. Models like the Spotify squads, bad agile practices or processes which instead of having a contribution in the team or an increase of productivity, make the team slower.

As a Software Engineer from the Payments Fraud team at cabify, I would like to tell you how we work and give you an overview on how I understand what is working in the Agile way.

I will start with some examples: plannings where you discuss about features that you did not know beforehand and you end up voting with a number in the fibonacci sequence, dailies used as a reporting on how busy you have been, use of tracking tools like jira where it is more important how long an issue has been in a column than releasing it into production, etc.

Have you ever been in that situation? I have.

If we read some of the agile manifesto we will find “Individuals and interactions over processes and tools” *and *“Responding to change over following a plan” are some values. We can get from them that it is more important how efficiently your team responds to a change instead of having a two weeks closed sprint which does not allow to add any task that will save your company some money.

Keeping that in mind, I will tell you how my current team works. We are a small team: a Product Manager, an Engineering Manager, three developers, a fraud stakeholder and some interactions with part of the data team. But this does not mean some of the following can not be used in bigger teams.

Our working practices are similar to what you could have in other product companies. We have a daily, a planning and something similar to a retrospective which we call “Fraud Club”. What is the difference then?.

The daily

The perfect daily definition is the one you do in 5 minutes and everyone goes back to their work quickly. In many teams the daily is done in a standing up way to avoid them being longer. Usually there is someone acting as a policeman to stop conversations that divert. It could be done in slack too in order to be async. It usually follows the model: What did I do yesterday?, What will I do today? and Are there any blockers?.

We, being a remote team and working from different time zones with up to 7 hours of difference, started with the async slack daily. But the amount of time we saved was later lost in different calls. So, our daily now is a 15 minutes zoom daily call between the developers which usually takes around 30 minutes and sometimes even longer.

Are we doing it completely wrong then? Not for me. That *hi! *when you arrive at the office, the coffee you have where you share some funny thing from your previous afternoon or just asking how everything is going where you live: On COVID times these are some ways we like to start the daily with. Of course, there will be days where we just start directly talking about work and it takes 10 minutes. Others, might be that even if we pass the agreed time we keep talking about some feature or merge request pending. I think, for teams which rarely meet each other, it is necessary to have some time to build a team and know the person you have in front of your call.

But what do we say about work? Probably you have been on what I call the I-have-been-busy dailies where you tell the others about the meeting you have had, how many people you have spoken to, etc. Above all, if there is some role like tech lead or similar, he will look like the busiest person. To me, this is a waste of time. Instead, we talk about something new released into production, if we have discovered any project/conversation that will help us with one of our problems or if someone keeps working in feature X, so the rest of the team knows and can help with some pairing or dividing the work into smaller pieces. Also, it is a good way using it for work distribution if you have your planning doc in front of you everyday.

The planning

We do our planning following this format on google doc:

I think doing the planning weekly helps us have more immediate feedback and allow us priority changes from business or from the team. Perhaps, this week we can dedicate a day to investigate a problem which we are not sure how it affects us or some of the stakeholders need something with urgency. The team can discuss if it has more priority than our current initiatives. To keep quoting the Agile Manifesto: “Responding to change over following a plan”.

We start rotating the operations role and asking about some planned days off for the week. The one who was in the ops role the previous week will be in charge of leading the planning. Starting from what things have appeared during the previous week. The ops role takes care of unplanned work like contacts from the other teams, some errors that were raised, etc. From there, there will be new tasks created if needed and depending on the urgency they will be taken immediately by the ops or any other team member. The ops will take care of our services metrics and healthiness but this is on every member of the team too.

Next, celebrations, which help people attending the meeting sync or async to know that something is already done/released besides keeping up with team motivation. Then we do the most important part: initiative focus. It means what is the priority right now for the team . It can be one or a few things, but having a limitation of one or two will keep the team focused during the week in the same objective, the same you do in Kanban limiting your work in progress. As examples, it could be to develop feature Y, put feature Z into production or simply to investigate if something is possible. Also, it could be the team has a new project which will take weeks or even months. Here we focus on just a smaller step towards the objective to avoid having every week the same one and to discover earlier blocked roads, instead of just focusing on the number of hours it would take to do a task.

Next, is week focus. In any company, there will always be many things to do that is why a focus is important. But by being multiple people in the team, not always everybody can work in the same task. Having a few options will allow a better work distribution. It is important that the list does not grow too much as even if you want to go faster, there will always be a limited number of things that will add some value within a week. These items could come from business but can be technical tasks as well(tech deb I am looking at you). From business, they will probably come from discussions during previous weeks that are now more relevant in form of a PID, from tech, we do from time to time a review of our backlog to clean up things that are not relevant anymore and if there are things that will bite us sooner than later, they are good candidates.

Another important part are dependencies. Usually between teams. At cabify, we try to avoid them as much as possible but this is not always the case. When there is one, we often unblock ourselves by contributing directly to the area that is blocking us. If this is not possible, having it listed weekly will remind you that maybe you should start a conversation in order to remove them.

Lastly, new topics. It is a way to bring new proposals to the team, either business or tech related. Basically they will end up in “coming up”, “week focus” or in just a conversation.

The club

Our meeting club is just a way to call a retrospective mixed with technical topics done by the developers and the engineering manager every two weeks. Everyone is encouraged to write new points in a shared doc and when the day arrives, if there is any topic, we will start talking about it.

We treat different topics, maybe questions related to the team/company more directed to the manager which could be something like a N:1 with your manager. But we start conversations about next steps on building new services or another example could be the famous “how we get out of the monolith?”.

What is the difference between “The Club” and a retrospective, then? Retrospectives I have been part of, often happen at the end of your biweekly or monthly sprint where the whole team will present and there will be some points added by everyone. The most voted ones will be discussed with a limited time per item and finally action points will be created. The problem is many important discussions will be avoided either because not everybody voted for it or because the time was limited.

Another benefit of The Club is that having it both synchronous and in a document allows our future selves to review the decisions taken.

It may seem that planning, dailies and a team meeting are too many meetings. But those are the only recurring meetings we have. The rest of the day we are free of them. We could have some general ones, like for the whole company but they are not mandatory and always recorded.

We have at least a couple of overlapping hours between team members in another timezone and the timezone in our Madrid office which is enough for the meetings mentioned before, plus doing some pairing, reviewing a MR together, etc.

Having that in mind, our calendar is almost free. Just imagine your first 5 hours of working during the morning without any meeting interruption.