Being Agile without Scrum

Today I am going to write about my experience at Plum. Almost a year ago, when I first joined Plum, we were in full startup mode. Many talented and motivated people gathered with the experience to create something big, but lacking in formalised organisation and procedures. Our development team was not ready to adopt a Scrum framework, but equally, we didn’t want to use a waterfall methodology to create our next feature.

From idea to delivery: the Plum way

Concept 💡

Well, before we begin, let’s take a step back. What is Plum trying to achieve?

Plum is a smart app that helps users grow their money. We are here to help people to be better with their finances.

Many people live paycheck-to-paycheck, with little or no savings. So we wanted to design a solution that could help.

# When do people struggle the most? 🤔

For people that get paid monthly, the most difficult period is at the end of the month.

Most of us remember our parents promising to buy us the (largely unnecessary) stuff we so desperately wanted as kids, when they got paid.

We understand that people tend to be overconfident immediately after payday, which can result in them struggling by the time month end rolls around.

# What can we do about this?

We identified that there were numerous ways to approach this problem.

- You can notify/judge people for their transactions, but we are not here to judge anyone 👨‍⚖️

- You can increase the amount in their paycheck, but unfortunately, we are not there yet 😅

- You can suggest a limit on the amount that users spend per day/week, and that might be something 💡

That’s the main concept! We need to make the users aware of how much money they can spend per day/week without even thinking about it.

Brainstorming 🧠

Awesome! We had the main idea, let’s figure out the details. This was one of the hardest parts. It required lots of team meetings, trying to think about edge cases, and how we should handle them. We spent more than two full weeks in meetings with almost no code written at all.

This is where we got a bit concerned.

# What did we do about this?

N-O-T-H-I-N-G. We are engineers, but we are not here just to write code. Our job requires providing solutions to problems. If this necessitates a lot of meetings, then so be it. Our only fear was that we were not productive enough, because we were so used to writing code. The truth is we were far more productive even than full-coding days. Once we realised this, we were more than happy to keep digging ⛏

# Reaching a solution 🎯

Eventually, we brainstormed enough specs to start building the MVP.

One of the trickiest parts was in defining how much the user actually has to spend.

A draft assumption could be that if the user gets paid £1,800 per month, this could be translated to £60 per day that the user can spend.

However, this assumption would be invalid, because everyone has bills to pay. It might be rent, car, household utility bills, or even bi-weekly music lessons. We knew that the actual spending money should be something like this formula:

spending_money = min(available_bank_balance, salary) — regulars_sum_until_next_paydate

User Interviews 🙋‍♂️

We might have been able to figure out the specifications for our idea, but we needed some additional validation.

Our team scheduled customer interviews to ensure our product was actually helping our customers. Everybody could join those interviews, it did not have to only be the PM or the designer.

We jumped on some calls. We asked customers about their challenges when it came to budgeting. I personally could not have even imagined how motivational I found it, to be making a positive impact on people’s lives. Everybody in our team was excited about the goal of helping customers to grow their money 💸

Although, when we shared our idea with them, some people didn’t like the approach and others preferred to tackle their finances manually, there were a lot of others who understood our point of view and were keen to give it a try!

That’s perfect, we validated the value of our feature, and we were ready to start working on it.

Breaking down the task ⚒️

As this feature was quite big and complex, there was no option to pick it up as a single unit of work. We had to **split it into many “sub-features”**. Engineers, the product manager, and the designer broke the feature into simpler tasks. For the more challenging ones, we had an engineer leading this, deep-diving into the existing code and giving them complete ownership on how this could be built/enhanced.

Define & handling dependencies 🕸

After the task breakdown, it was clear that some subtasks depended on the domains of other squads. For example, we had to interact a lot with the Payments team to create some automated transfers.

One initial problem was that the payments team had its own backlog, and they could not afford to spend time building our feature 😬

In some companies, this might be a blocker for the feature, but not for us. We went ahead and developed some logic on the domain of the payments team, and just asked the code-owners to support us as much as they can.

We followed this approach for every cross-squad dependency, and it worked really well. It might not be feasible to do something like this in a big tech company, but for a fast-growing start-up, it seemed like the best solution to this problem.

Prioritizing features 📋

One of the ways we are able to implement a quick feedback loop and enhance a new product feature is by releasing fast and constantly enhancing the feature until we’re happy that it delivers real value to our customers.

A real example of this was when we launched our budgeting feature. We released the MVP, and once we’d obtained some initial insights were able to enhance the initial functionality.

Developing 🏗

Finally, we get to the part that every engineer really likes (I hope at least 😅). We know what we want to build, how it should work, and having explored most edge cases, we have a rough idea of what can change in the near future. Mobile and Backend engineers were able to define our API contracts to perform the proper modeling and we were all able to write automated tests to ensure that what we built worked as expected.

It’s fair to say that the development process was pretty smooth. We identified some new edge cases during the development, but the team was proactive and with the proper communication we made it through.

Getting closer ⌛️

So after developing the feature for a while, we could see that we were getting closer to the release… but we were still not there yet!

There were some frustrations within the team, because we wanted to deliver and there always seemed to be something else blocking it. So we decided to try a team activity in an attempt to find a workaround. In each meeting we started asking ourselves:

If we decided to release our product next week, what do we estimate we could have ready?

Every engineer started estimating what tasks could be completed each week until we pinpointed the perfect week for the initial release. It’s important to emphasise that this “date” was **an internal team goal, not a deadline**. We all know stuff can happen and software can get delayed, and that’s fine. We are doing our best and we trust each other. If we fail to achieve our goal that’s fine as well, building a company is a marathon, not a sprint.

Releasing 🚀

Finally, we made it and we’re ready to release. Let’s press the deployment button and ship to more than 1 million users, right? What could go wrong? 😅 Famous last words. No, we need to make the release as smooth as we can.

Plum employees are our first testers. We find some early bugs, we fix them, and we move on.

We then created a waitlist, before the release, for more eager customers to enroll. These are our second group of testers. Again, we find some bugs, we fix them, and then we enable the feature to a small percentage of the customer base. We repeat the same process of finding and fixing bugs, and gradually rolling out the feature until it’s available to every Plum customer. 🎉

Conclusion ✍️

Shaping a new team is challenging. It takes time, and it’s different each time. Almost every engineer enjoys working in an agile team and bringing incremental value to the company. Scrum is a great tool, and its basic points can really help a team shape and find some common ground. However, you do not need to adhere to Scrum to be Agile.

Ultimately though, the only thing you need is a short feedback loop. Then, you need to adapt based on the people, product, company, and consumers. As long as trust and transparency are established within a team, any other challenges can be easily tackled. 💪

As we agreed 🤝 (both hands are mine), we are here to provide solutions, not just to write the code for them. This is not limited to the features we deliver but to the ways that a team/company works.

We would love to hear your thoughts about this. Do you have any ideas about what we could improve? Feel free to reach out, or even better, join us and make it happen 😉