Startup Agile

The Moneybox team has trebled in size over the last year. While expanding the team has been an exciting time for us and is key to making our app the best it can be, some teams have needed to make adjustments in order to keep up with the needs of the company as we grow. In this edition of our tech blog, our Head of Engineering, Sian, outlines the changes she’s made to the workflow of our tech teams since joining.

“A year ago when I started at Moneybox we were a very different company but a lot has changed as we’ve grown and scaled.

I started my job as Head of Engineering at the same time as Ed, our Head of Application Architecture, and with very aligned remits and goals. When we arrived, Moneybox was coming out of the tail end of being a true startup, the kind where you have a small number of people who all sit next to each other and understand exactly what each other is working on and, from a tech point of view, know most of the codebase inside out. Success had meant the company was starting to scale to the point where processes and ways of working that had been great for a smaller organisation were no longer working as well. My challenge was to try to find ways of helping with that without losing the team’s ability to make fast pivots to meet new business challenges, and without damaging our startup “hustle” to get things done.

So what did I do? I started off by introducing the most lightweight of agile processes, unfashionably picking Scrum rather than Kanban because I wanted to set us the target of planning our work at least a little bit in advance. I also worried that going from adhoc to Kanban would almost certainly end up as waterfall, because the building blocks that needed to be in place for Kanban weren’t there. Then I threw out a lot of the “must haves” of the Scrum process if I didn’t think they were going to work for Moneybox as an organisation.

Some of the changes we made to the Scrum handbook: at that point, our amazing Product team consisted of one individual (now at 7 and climbing!) and the UX team were also stretched, so insisting on perfectly designed “Definition of Ready” tickets at the start of each sprint was a non-starter. Instead, Product aimed to have tickets in the best state possible for the refinement and for the start of each sprint, with the best Zeplin designs that the UX team could pull together. As a tech team, we also accepted that we needed to be collaborative and understand that sometimes those things would be in progress as we started work.

In the same way, after a debate about sprint lengths (and about whether sprints were even achievable given our rate of change) we settled for “we’ll try our best to keep our plans stable for 2 weeks and to deliver a releasable increment of work”, knowing that sometimes that stability wasn’t going to occur, and that was OK — we were ready to pivot when it met the company’s needs or changing strategic goals. We also started showcasing to the whole company every fortnight, which gave us meaningful feedback from our key stakeholders and also gave our Customer Delight team, who interact with our users every day, opportunities to ask questions about changes to the app and the product.

Throughout the change process our attitude was, “Let’s give it a try”, and we made sure to remember that any part of any process that didn’t work for us could be changed — nothing had to be perfect or fixed in stone. We then started to work with what we had. The changes people were the least keen on at the start turned out to be some of the most popular innovations over time. For example, there was a lot of concern that showcasing to literally everyone at the company who was interested would be disruptive and take up too much time from busy teams but, once we started, even some of the most sceptical stakeholders were pleased with the outcome.

Over time we evolved our ways of working further to help us deliver for the business. One of our team leads introduced event storming after attending a conference — this has been enthusiastically embraced by both the product and development teams and has become a great process tool. Our Android lead realised that we were losing a lot of time on stories going back and forth with the UX team, and introduced a small “UX refinement” session so that the relevant people could be sure they were on the right page about how the app was going to look.

We haven’t stuck to Scrum throughout, either. We toggled to Kanban for a 3 month period while we rebranded the app, accepting that even a semblance of predictability wasn’t possible as new designs were drip fed through from the designers as fast as they could produce them, then switched back after a successful delivery.

Overall, we’ve embraced the fact that rapid change of priorities is a part of our life and try our best to be ready for it when it happens. App releases are now much more predictable, and we generally have a good idea of what we’re releasing when, which was not the case 6 months ago, while at the same time we’re able to enthusiastically embrace curveballs with quick delivery dates. The rhythm of loose sprints has also helped knit the tech teams closer to their collaborators in Product and UX, as we all work towards a common goal without being overly rigid.

I knew that we had the right mix for us as a team when the Covid-19 lockdown sent us all home from the office and by the next morning everybody was working from their own homes utterly unphased, showing up for stand-up online, talking to the people they needed to talk to and just getting stuff done. I don’t doubt that our processes will change again as we scale again over the next year, but we’re doing the right things for us right now to be able to deliver without getting too stressed out about it, and that’s great — I’m really proud of what we’ve been able to achieve together over the last year!”