The rise of distributed teams is transforming how we work and setting the stage for global collaboration.
No longer confined to a single physical office, an engineering team could be based in San Francisco, but have distributed team members that live and work in New York, London, and Lagos.
Many companies are embracing and restructuring around this new model of work to attract and retain the best talent.
Although tools like Slack and Zoom can connect teams instantly, they don’t meet all the communication demands of distributed engineering teams. They must also be armed with powerful collaboration tools.
Retrospectives, a critical component of the Agile process, is where teams reflect on the development process and look for areas to improve.
Conducting a distributed retrospective isn’t as simple as calling a remote team member via video conference. It’s an interactive process that includes a series of activities that, at times, require anonymity.
Founded in 2019, Retroly is an agile retrospective tool for teams with remote or co-located team members. The application guides teams through industry-approved activities to ensure they run a successful retro every time.
I spoke with Seun Akanni, Front-end Software Engineer and co-founder of Retroly, about building remote retrospective tools, differentiating their product from its competitors, and Tech in Africa.
How did you translate Retroly's requirements into code?
Retroly is designed to get the best out of an agile team’s retrospective.
From the Scrum Master’s perspective, a traditional retro includes:
- Asking team members for feedback
- Writing comments on a sticky note,
- Pasting the sticky notes on the whiteboard
- Typing up the notes in an excel sheet or word document post retro.
Initially, the problem we sought out to solve was to make the process more seamless for Scrum Masters and keep remote team members fully engaged throughout the retro. But as we began to research, we found out not only could Retroly be used for this purpose but also planning, meetings, idea generations, and brainstorming.
Once we figured out the actual problem we were trying to solve, the first stage of translating the requirements into code was research.
We learned how challenging running retrospectives were for teams with remote members, and that participating via video conference wasn’t sufficient for the interactive process.
We studied the existing solutions, like Trello and many other similar products, and felt that they were too complex. We decided to break our retrospective into four basic stages, which has proven to be useful for everyone that uses the product. We have the feedback, group, vote, and resolution stage, each with their unique features.
Retrospective Stages:
The Feedback stage is where everybody in the team adds their feedback. In our research, we found out that just having a place to enter feedback wasn’t enough, so we gave users additional categories like ideas and suggestions.
We also added a feature called Live Feedback, where you can hide your comments until the second stage. We realized that someone might be unwilling to share their remarks if their manager gives some suggestions that go against their own. And if you cannot post comments from your point of view, then it negates the whole idea of retrospectives.
The next stage is the Group stage. Once all the feedback is into the system, you group similar comments from the feedback stage together.
The third is the Voting stage, where team members vote on their preferred idea or feedback. The Scrum Master determines the number of votes per person. For example, if you set three votes per user, each person can vote three separate times.
To give users the option to spend all their votes on one feedback, we added this feature called multiple votes. So if you have an idea you think the team needs to implement, you can use all your votes on it.
The last stage is the Resolution stage.
Global Solution:
Surprisingly, when we put Retroly out into the world, we found out that it was people in France who embraced the product. Every day about 60% of our users are from France, which is funny because when we were building, we never thought about France. We even got featured on a top tech blog in France.
Most of our users are in France, the UK, the US, Germany, and Canada. Some days we’re like, what’s going on in Africa? But I mean, it just shows that people really like the solution and are making use of it, which is really good encouragement.
How important is it for developers to work with UI designers when they’re building products?
It’s a very important relationship because, as a front-end developer, you need that pictorial visualization of the problem you are trying to solve. Sometimes when you see the problem displayed in pictures or diagrams, they’re easier to code because you can see it.
Also, many factors go into building a user-friendly solution. As front-end developers, we don’t know or consider everything. UI designers do a lot of research on human-computer interaction and how to represent the solution functionally but also nicely.
What role did empathy play in building Retroly?
Empathy played a very important role because we’re building for users, and the goal is to have a minimal learning curve when using our application.
We believe that the less time a user has to spend figuring out how to use a solution, the higher the chances they’ll want to use the product again and recommend it to others.
As a developer, you are meant to solve the user’s problem, not add more problems. You don’t want your solution to be so complex that users have to watch YouTube videos to understand how to navigate and use your platform.
Sometimes even as an engineer, I come across applications that I have to go to YouTube, which is an added stress. So throughout the design process, we had to think, what’s the simplest way the user can do this.
What were some of the biggest challenges you faced building Retroly?
Initially, communication was an issue. Not only were we unable to work together physically, but we were in two different time zones — my co-founders (Biyi Adetunji)in the Netherlands, and myself in Nigeria. So communication was tough at first, but we found ways to bridge the gap.
Also, him being a designer and me an engineer, sometimes, when I’d try to explain or share ideas using engineering terms, it didn’t always resonate. So I found alternative ways to explain, whether it was sharing my screen or breaking down the terminology.
Deciding what technologies to use to build Retroly was also a challenge. We researched the technologies our competitors were using and the alternatives available. Once we had a solid list, we listed out the pros and cons of each to determine which technologies to use.
Another challenge was the user experience. My partner designed the UI with a lot of nice interactions, “when you click on a button, this should happen, or this is what should happen when the page is loading.”
But a lot of these experiences were difficult to achieve from a development perspective, so we had to go back and simplify. We realized that building an application is not all about beautifully designed user interfaces and writing a bunch of code. It’s about creating a great experience for the user.
You mentioned that in Africa, sometimes employers don’t take chances on young talent. What do you mean by that?
Here’s where I’m coming from; if you have little to no work experience, less than one year, most companies here in Africa wouldn’t take a chance on you. They usually want someone who has two years plus of experience, and I always wonder, “how am I supposed to get experience if you’re not going to employ me?”
This is a huge problem in this part of the world. Unless you have someone somewhere that can speak for you, it’s hard to get a job with little experience. So what you see people do is build their own product to showcase their skills, or go to Upwork and Freelancer.com to find side gigs.
As a front-end developer in Africa, at times, your best bet for getting a job is having a UI Designer as a friend because whatever they design for a client, you can sweet-talk them into asking their client if you can implement it.
Built In Africa? What does that mean to you?
When I hear Built In Africa, I think, stories of the products and ideas that are built or owned by Africans. It doesn’t necessarily mean that these ideas and products are confined to the continent of Africa or a single country or a city. It’s inclusive of all products that are linked or traced to African roots.
Stay up to date with our newest posts and special happening here at Built In Africa. Your information is safe with us, we hate receiving pointless emails also. :)
.svg){kind=small}
