JUMO is a financial services marketplace. Using behavioural data from mobile usage, their predictive technology creates highly accurate credit ratings for people - a “JUMO score”. Targeting emerging markets, 80% of JUMO-customers interact with banks for the very first time.
Founded in 2015, JUMO currently operates in 6 African countries: Kenya, Tanzania, Zambia, Ghana, Uganda and Rwanda, and will soon be launching their services in Pakistan. In addition, the company has recently become the first South African startup to be selected for the Google Launchpad Accelerator.
JUMO’s development teams are based in Nairobi and Cape Town. Director of Engineering, Aveshan Govender, answered our questions on their development processes and how he sees his role in the team.
You left Allan Gray to join JUMO. When exactly did you join, and why?
What I saw in JUMO was the potential to really contribute to something with a genuine social impact. It is an opportunity with tremendous scope: our three-year plan is to reach 100 million customers. That really excited me and when I visited the office the first time, I could sense that same excitement in the building - it was palpable. I came in, met Ted (Pietrzak), met the engineers, and it was like: “I can't not be here. I have to be here.”
The developer team itself is also at an exciting stage. When I started in May 2016, it was a team of eight, now we’re a group of 40 doing standups in the morning.
Let’s jump into the details of the developer teams. How big is your team, and how is it configured?
We currently have 27 developers supported by three Development Managers, five Agile Leads and three Architects.
They’re organised into six individual teams that we call squads. Squads are fairly static and consist of four to seven developers, each supported by a Development Manager, an Agile Lead and a Product Owner. Architects are not assigned to teams, but to initiatives. We aim to build long term cohesion in squads, so we only make minor changes to the members.
We’ve had this structure since January this year. Before that, we had three teams cycling over a few things - either feature development or maintenance and support.
Why was it necessary to change the structure of the team?
We realised that we were losing long term ownership of particular products. We wanted to build a nice bridge between generalisation and specialisation in particular domains of the system. That’s why we’re now evolving to the next model: six teams with specific responsibilities who each own a set of domains.
We currently have one team who owns support, but the idea is that they would eventually roll off and that each team will own the support for the things they build.
The domains must also still be figured out. At the moment, the teams are still building specific products in defined spaces, like Savings, Activations or Microservices.
What is the difference between the Development Managers and the Agile Leads?
In practical terms, the Agile Leads look at processes and the Development Managers look at tech. An Agile Lead will stand back a little bit, look at the team and how they’re cooperating and ask: “What can we do to make velocity better?” or “It felt like we didn’t run a great retrospective last time. How can we make that better?”
Development Managers will ask things like: “We have to create this product in the next three months. What is the best way of tackling it? Have we thought about product quality enough?” They also focus on individual skills to figure out what kind of coaching someone would need.
Now, when it comes to building products, how do you approach it?
Okay, there are a few key elements to JUMO's process: initiatives, influencers, prioritisation, pods, epics, stories and sprints.
So let’s start at the top:
In our world, initiatives describe the creation of something. Anyone at JUMO can come up with initiatives, but the Product Team takes ownership of it. They look through an initiative lense. We’re currently working on four initiatives and have another three in the pipeline. The backlog lies at around 12 to 15.
Once an initiative is tabled, the first task of the Product Team is to get all the right people in the room to talk about it - that’s where the influencers come in. So we’ll ask: “What do we need to take into consideration? Who do we need to consult to make sure the initiative has the best chance to succeed?” The output is a bit more defined - stipulating the goals of the initiative, the releases and an estimate of the size of the first release.
Releases are the subunits of an initiative. That is the unit of work a team will take on. We think about releases in T-shirt-sizes: Small, Medium, Large and so on. The size itself is usually determined by an Architect, the Product Owner and some developers.
Once initiatives are defined and the releases sketched out, the project goes through the prioritisation process. We have a prioritisation slot every Monday where the company as a whole gets to vote on initiatives. We do it on Survey Monkey and use rating metrics like strategic risks, platform risks, reputational risks and financial risks. Based on the thus created value score, we build our “value ladder” - it’s not necessarily the execution order.
The execution order is determined by the engineering team. We’ll say: “Okay, we currently have so many things to build, these are the moving pieces. We can’t build product A yet because we need this microservice to be in place. How do we factor that in?” So execution order is a combination of product strategy and tactical engineering strategy.
Once we’ve figured all of that out, we create the pod. Pods consist of anyone that would influence the development of a product or feature. This team is transient and includes people from across the business as well as a specific squad of developers.
Let’s talk about your sprints for a bit. How do they work?
We have two-week sprints across all teams.
Before a sprint starts, we do some work to ensure that we have a good grip on the scope of the sprint. That kind of prep would involve the Agile Lead, the Product Owner, the Architect and the Development Manager - whoever is needed to determine the scope. That means, the specific release we’re about to work on is broken down into epics and stories.
Epics are tied to initiatives. Let’s say we’re working on Initiative X: a specific component or feature of Initiative X would be an epic. We’re still refining this, but an epic may take longer than one sprint to complete.
Stories are much smaller. They take about three days to complete. It will be a specific screen, for example, or a user journey.
Day 1 of a sprint is planning and sprint kickoff. In ideal circumstances, the Architect will already have a strong view on the epic the team will tackle. Together, they will then disseminate this idea during planning, asking “What does it mean for us? How do we build it?”
The other components of a sprint are:
- Daily standups per squad - mostly around a physical board adapted to the specifics of the team
- Backlog grooming - that’s part of the normal cadence of the team. They look at the stories and epics they have lined up, unpack them further, get estimates. It’s very much driven by the product owner who’ll go: “This is what we have to build next. This is the next epic or set of stories we should tackle.” The team will then get involved and discuss it together.
- Retrospective on the last day of the sprint - involving only the squad
- Demos on the last day of the sprint - involving all members of the pod
- One-on-ones - each developer meets with their Agile Lead once a week
What aspects of JUMO’s development process are you not happy with?
We really have a lot to still figure out. As with most digital business, there is an element of low-touch between those of us building the product and customers who use the product. Customer satisfaction and active subscribers are very important metrics to us. Our customer intelligence team helps make our customers visible to those of us who are building products and solutions for them. For example, we spend a lot of time creating user personas user personas as an attempt to close that gap.
To wrap it up, I’m curious to know how you think about your own role as Director of Engineering. How do you see your role?
I follow a model that is aligned with Dan Pink’s model for motivation: purpose, autonomy and mastery. My focus since day one has been growing the team in those areas.
For me, the purpose is in understanding how the products we build affect real people. So it is about understanding the impact of our work on a high level.
I also emphasise the importance of being a world-class developer team. By being excellent, the impact of our work is bigger and deeper. That also connects the high level purpose to individual purpose - someone aspires to be an amazing engineer for specific reasons.
I take responsibility for making sure those things are talked about on a weekly basis.
Product demos also help with creating a sense of purpose. Our CEO, Andrew, attends most of these demos and provides a lot of meaningful context.
For me, autonomy comes down to three things: knowledge, assistance and resources. Give people all the knowledge, assistance and resources they need to do their work and then get out of their way. It is like saying “If you get stuck and you need to ask for directions, this is who you ask.” It can also mean to get people a better laptop or create a new type of meeting for better results.
The idea of mastery is particularly important to us, so we have a few initiatives around it.
Noobschool, for example, is our “Getting Started Guide” for new team members. It provides an overall review of the architecture of our system, shows you how we debug something, explains our coding standards - those kinds of things.
We also focus a lot on training and mentoring existing staff and are currently working on making that more formal with the help of our Development Managers.
Then we have a bi-weekly Craftsmen Academy, which is our tech forum. Last week, someone showed us the Apollo 11 source code, for example. This is an important space, because it’s driving different thoughts. It might not necessarily be aligned with what we’re doing right now, but it does get people to think and talk about new tech.
JUMO is hiring on OfferZen. Click here to sign up.