Converting to Agile from the bottom-up: a story of a fintech startup
“We need more processes at Fidel.”
Said Andre, Fidel API’s co-founder and CTO, when we first met about a year ago.
Having witnessed three major Agile transformations in some of the most prominent Nordic banks – i.e. now knowing what NOT to do – Fidel API for me personally was an opportunity to get it right. For once I would not need to beg to convert siloed departments into small and nimble cross-functional product teams that are focussed on delivering value to customers fast. Joining Fidel API in 2019 was an opportunity for me to combine the best there is about Agile ways of working (WoW) with the unique culture of an ambitious company – all from the bottom-up. Naturally, – I was up for the challenge.
It helped a lot to find out that the ten engineers at Fidel API – when I first started there – were already quite experienced. Perhaps that was the reason behind Andre’s sense that “we need more process”. You see, ten engineers isn’t a lot, but even then there were some warning signs that things weren’t operating smoothly.
Firstly, the product roadmap was not aligned with the team structure, so many of the planned products had no people working towards them. Second, the engineers had split themselves into the traditional frontend and backend teams, mixing only occasionally. Hidden work was slowing down the most senior members of the engineering team (everyone knew which developers could fix anything and fast). Professional task and information management tools were not in place. The only product owner we had was Andre, who was becoming increasingly busy with strategic projects. The perception was that engineers work on the technical stuff rather than contributing to creating the value we deliver to our customers.
From the reaction I provoked after suggesting some fundamental improvements, I quickly learned that introducing new things at Fidel should all be done bottom-up. This was in stark contrast with the large corporations where Agile WoW are usually pollinated by management consultants who sell buzzwords (e.g. “Spotify Model“) to the top management. Then it either grows into a full-blown Godzilla Agile transformation (e.g. introducing SAFe) or trickles down into some diluted version of Agile without changing any actual thinking or, more importantly, our processes.
Getting Started
OK, so, no top-down approach – but where do we start? I started with a half-day ideation workshop during our 2019 Christmas get-together in London. This was an opportunity for all engineers to figure out the biggest pain points and in many cases even their own possible solutions to their problems. This was a bottom-up Agile transformation. And yes, I was excited.
In a very simplified speedboat retrospective, we first identified five fundamental areas where improvements are needed:
- Backlog management and setting of priorities
- Effective teamwork
- Improving planning & predictability
- Showing our work to others and engaging stakeholders
- Continuous improvements
Then, engineers worked in pairs by applying elements from the open space model to ideate on these pain points. We ended up with tons of ideas which we were able to distil, discuss and prioritise in concrete agreements and actions. Some of the agreements were easily implemented, for example:
- Reflect all work in backlogs (make work visible)
- Move only prioritised work into Sprints
- Don’t work on tasks that don’t contribute to the sprint goal
We also agreed on what we need to do in the longer term – such as:
- Decide on the definition of ‘done’ and definition of ‘ready’
- Introduce Jira & Confluence
- Re-organise into product teams
- Agree on estimation techniques
- Create a buddy system
- Organise regular re-factoring weeks and others
Fast forward to the end of 2020 – we had all this and much more. Fidel API had four full-blown product teams working in Scrum, guided by three hyper-charged product owners. We had well integrated the new process management tools and there is a stable velocity across the teams giving us the confidence of two new product deliveries that year.
Most importantly – we’ve preserved the high spirits and desire to reinvent ourselves for the continuous betterment of our collaboration at the company.
Good Habits
In the following years, I kept on introducing future improvements in the same original way: bottom-up. We started with a little workshop for all engineers where I explained the best practices that are out there; sometimes engineers trialed them a bit to get a taste of what the new process means in practice (e.g. relative vs absolute estimation technique). This is always followed by a discussion with the objective to decide which pieces of the “best practice” we adopted and in what way.
Usually, it was the “best practice” with a characteristic Fidel API flourish added on top. For example, we’re committed about having some Scrum events such as Sprint Reviews, Retrospectives and Sprint Planning. However, we tried to limit the time for these events to two hours altogether; it was part of a wider goal to minimise time spent in meetings (hence, we also had ‘no-meetings Tuesdays’ across product teams).
You could call it ‘Agile + common sense’. That’s because Agile and Scrum are just tools, not rules, so we used the tools to support the best outcomes for us. At the end of the day, what matters is that we worked better and people were happier. I am proud to say that, at Fidel API, we’re able to work towards that goal every day.
