How Fidel Is Converting to Agile From the Bottom-Up

“We need more process at Fidel”, said Andre, Fidel'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 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 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 - 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 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:

1. Backlog management and setting of priorities
2. Effective teamwork
3. Improving planning & predictability
4. Showing our work to others and engaging stakeholders
5. 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 now - we have all this and much more. Fidel has four full-blown product teams working in Scrum, guided by three hyper-charged product owners. We have well integrated the new process management tools and there is a stable velocity across the teams giving us confidence of two new product deliveries this year.

Most importantly - we've preserved the high spirits and desire to reinvent ourselves for the continuous betterment of our collaboration at Fidel.

Good Habits

Even now, I still introduce future improvements in the same original way: bottom-up. We start with a little workshop for all engineers where I explain the best practices that are out there; sometimes engineers trial them a bit to get the 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 adopt and in what way. Usually, it's the "best practice" with a characteristic (blue?) Fidel flourish added on top. For example, we're committed about having some Scrum events such as Sprint Reviews, Retrospectives and Sprint Planning. However, we try to limit the time for these events to two hours altogether; it's part of a wider goal to minimise time spent in meetings (hence, we also have ‘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 use the tools to support the best outcomes for us. At the end of the day, what matters is that we work better and people are happier. I am proud to say that, at Fidel, we’re able to work towards that goal every day.