Developing a new product quickly in a fast pace environnement

Introduction

In June 2020, we started to hear about a new mobile application in a strategic meeting at LumApps. This new app was intended to target a new kind of users.

It involves new features that have never been done at LumApps and also a short deadline, end of September (that is to say 3 months only to develop a new application!).

During our development process we have strong standards such as units tests, reviews, testing to always have a good quality in our releases. In this specific scenario the main objective was the short deadline so we had to use some shortcuts while keeping a good quality.

At the end, we managed to have an MVP at the end of September while keeping (almost) all our standards. This article will cover different topics which can explain how we were able to do it. Throughout this article, I’ll never mention iOS or Android platform even if, for different reasons, we’re not at the same level on every subject we do have the same philosophy and goals.

CodeBase

Probably the most important point is the codebase. If you’re working on a project with strong technical debt or/and no defined architecture there is no chance for you to get things done quickly. You’ll face too many difficulties such as regression, strong dependencies, duplicate code which will get in your way and slow you down or even prevent you from doing the enhancement or feature you want to achieve.

From the beginning of the mobile applications development (3 years ago), architecture, clean code and refactor have always been our main priorities. We’re proud after all this time to have a quality project which allows us to implement new features easily without affecting the rest of the project. Every team member is involved in this task and we keep improving our architecture as the project grows.

Team

In the mobile team, we are lucky enough to have mostly senior developers which is very helpful to keep a clean project thus not mandatory. There is some very important subject that shouldn’t be underestimated.

Although you might come from different companies, might have learned different frameworks, architecture, coding patterns. All those experiences are useful only if all team members are going in the same direction. If anyone is coding on its own without paying attention to what has been done or should be done, your team is wasting a lot of time and energy.

In the mobile team, we have a defined architecture (don’t hesitate to read this article from last year) that we always follow. We review each other all the time to avoid duplicate code, to make sure that all our standards are applied and just to be up-to-date of what the others are doing. It could seem a bit tight. It’s just the opposite, we’re always discussing how we can make our project better, what new tools can we use from update we get from Google/Apple and we look for better solutions as our project keep getting more and more features.

It’s impossible to have the perfect architecture or coding patterns because it depends on a lot of elements such as the complexity of the application you’re working on, the size and experience of your team, the time you have to achieve your feature and much more. But it’s important to keep in mind that your project should always evolve and you should solve issues you can have before it’s too late and you can’t turn back. Of course, this should be done by discussing with your team members.

Minimise human mistakes

CI

We have been using continuous integration for a while now and it helps us for different tasks. If you want more technical details about it you can check this article.

We now have multiple targets on the same project and it can be difficult to maintain. Every time we have a new PR, GitHub actions check that every test pass and that all targets are compiling without any errors. It did prevent us to merge a PR with a target not compiling a couple (and more) of times.

We now give the possibility for a client to have a specific logo for their app and being able to deploy it without using LumApps generic one. From a mobile point of view, it is a difficult task because it means having to deploy every custom app and also to do it every time we want to update to have the latest features. It would be impossible to do it without a CI process which we now have!

CI requires a lot of investments but it is a big asset for us and it keeps involving with our project.

Unit tests

We always see unit tests has a great tool to develop. It’s right, unit tests help you to have flexible code (if you can’t easily test a specific part of your code you’re probably having too many dependencies which lead to rigidity), spend less time debugging and can also explain a complex algorithm just by reading all different tests scenarios.

But we often forget that it’s one of the best tools to avoid regressions. If you want to refactor a part of your project, how can you be sure at the end that everything is working as it was before if you don’t have tests on it? There is no way you can anticipate all behaviours of a class or a feature if it’s not 100% tested. Because we’re working on a product which is available for many years now and will be for years to come, regression is probably our worst enemy and units tests (and even UI tests) are the tools we must have.

Keep a good focus

One of the biggest challenges we faced during this project development was the unknown. We had to quickly start development to catch up with the concurrency and this was contradictory with the fact that we weren’t sure of what we wanted…

We started by focusing on one of the main features: Chat. After a few days trying the first SDK, we quickly switched to an other service which is the SDK we use on the MVP. On this feature we managed to progress quickly thanks to the documentation and the SDK which had all the features we needed, it’s only after 2 or 3 weeks that we focused on design.

The other big feature was Workflow, we decided to use a web view to get help from another team. It was a lot of work for them and we made sure to help them as quickly as we could to avoid wasting time. The final implementation was near the end of the project but it wouldn’t have been possible without discussing and being available during several weeks to test the feature on mobile when needed.

The last feature was Documents, this came very late in the process and we only worked on it in the last weeks. It was difficult because this feature wasn’t ready on backend and frontend side. Working with the backend team we managed to get something going just before the end of the project.

Organization

An Agile Scrum organization was implemented.

Sprint:

• 2 weeks
• Unique Jira board for all the developments teams

Meetings:

Every day:

• Written daily

Every week:

• Project weekly (progress reports concerning the deals with the customers and the developments, highlight on the blocking points)

Every 2 weeks:

• Demo (every feature available in the new application was showed, even if it was not 100 % ended or validated)
• Sprint planning

This organization was facilitating the communication between all the teams, as explained just after.

Communication

An important skill we used during this project was the communication between the teams (technical, product, project management, CTO, etc.).

As soon as a developer was facing a blocking point or difficulty, he warned immediately the developer manager, Product Owner and Product Manager. They discussed the issue :

• If they succeeded to found a solution, they shared it with the teams;
• If they failed to do so, they contacted the CTO and when a solution was found (most of the time within the day), it was shared with the team.

A meeting minutes was delivered just after each important meeting, so that the decisions taken could be checked in case of doubt.

These reports were also useful to prepare the QA session at the end of the project. Several coordination meetings were also organized during the week (see « Organization » section), so that each stakeholder was aware of the advancement of the project.

Another great example would be the test environment. We faced the difficulty of having all features deployed at the same time. We needed to synchronise a lot with the other teams (not only those working on this project) to test everything on a single environment which at the end didn’t delay us that much.

Conclusion

Of course, everything wasn’t perfect, we first created a new project to finally come back to our main project but use a different target. We had a lot of back and forward mistakes at the end of the project. We had to move to a new chat SDK. We worked on a community feature to finally use the community post feed we have inside the app without changes. And also we ran into lot of trouble to get a stable environment. Thanks to a big focus on reporting, and discussion between all the teams involved, all those mistakes didn’t impact the deadline and were discovered early in the process.

To summarise what help us during this time

• A solid codebase
• A great team
• Focus on the things we knew won’t change
• Apply design only at the very end
• Help other teams as quickly as we could to avoid being stuck (Workflow)
• A structured organization with important steps, such as demos every 2 weeks
• Reports and communication between teams