As a stakeholder in a mobile development project, one of the benefits of developing a product using the agile method is to simplify communication within the team. To avoid technical language, the team exchanges using functional terms.

But, even in the absence of technical terms, the success of your project in the medium and long term depends on the quality of the code produced by the developers. In this article, you will find tips for managing this quality throughout your project.

Don't be afraid of the technical complexity of this article, it's for everyone!

Your key word is: technical agility.

The objective of technical agility is to reduce technical debt and to make the project maintainable and repeatable. That is to say, ensure that the resumption of the project by a new team will be inexpensive. For example, when a BAM project comes to an end, technical agility allows our client to have the project taken over by its own developers without wasting time, and therefore without “wasting” money. But technical agility is just as important during development, as it ensures that new developers who join the team can start developing quickly without delaying the project.

How do I manage the technical agility of my project?

To manage the technical agility of your project, you need “standards”.

What is a standard? The standard is an objective defined by the team that allows it to succeed in the project. Example: I want to develop a mobile application in an agile way with frequent user feedback. To achieve this goal, I set a standard for myself to have one user test per week. Every week I will check whether my standard is respected or not. The follow-up of this standard can be materialized as follows.

Non-compliance with a standard represents a risk for the project. It serves as an alert and a point of attention for the team.

Technical agility standards at BAM

These are the standards that help the BAM teams to manage the quality of the product code for our mobile projects. These standards are indicators created by experience. Through the successes and the failures, we learned that the following 7 points were crucial to the success of a project. This is how our 7 technical agility standards were born. They can obviously be used to manage a non-BAM project.

Ensure that these 7 standards are respected and you will eliminate significant risks from your project.

No. 1: Code vocabulary is identical to business vocabulary

The code must use variables that are those used by those in the business in order to prevent bugs or wasting time by creating additional work. Example: In a local news delivery application, a key metric was the neighborhood of users in order to provide them with the appropriate information. The tech team created a “neighborhood” metric that was actually the postal code. During the project, the team realized that people in the same neighborhood could have different postal codes (like some Parisian districts). In addition to an application that did not deliver information to the entire target, this caused bugs and therefore additional work to make the application usable.

No. 2: Stable and up to date dependencies

In applications, developers don't code from scratch, they use “libraries” that are available to everyone. These libraries make it possible to speed up developments by capitalizing on code already written by other developers. But these are being improved and expanded continuously, so the team needs to update the code with new library updates, otherwise the “borrowed code” may no longer work.

The advantage of following this standard week after week is to update as the library evolves, and therefore avoid expensive and complicated updates after several months without updating.

No. 3: Destruction of the environment

By destroying their environment every week and reinstalling it in less than 15 minutes, members of the technical team ensure that the documentation added as they develop allows any developer to resume the project easily.

NB: the environment is the set of tools installed that are used to develop.

No. 4: At least one refactoring per day

Refactoring consists in reworking your code without adding features but simplifying it. The objective is to keep the code readable and more easily maintainable. By requiring at least one refactoring per day, the technical team is obliged to work on the readability and quality of its code.

No. 5: Code coverage is increasing

Code coverage = test coverage (%). Example: I have 10 lines of code and I am testing 5 lines. My test coverage is 50%.

The technical team codes automatic tests that verify that the written application code works correctly. For test coverage to increase, it is therefore necessary to develop code tests in parallel.

The more automatically what has been created is tested, the easier it is to identify bugs and regressions.

NB: A regression is the fact that a feature no longer works when it worked before.

No. 6: Build and deploy in staging and production in one order

Deployment is the action of passing code from a developer's computer to an application that can be downloaded on a smartphone. There are a lot of steps to get there. The aim of this standard is to automate this process, in order to save time and avoid human errors along the way.

No. 7: green continuous integration across all branches deployed

When there are several developers who code, they create branches: each code on his own. The standard makes it possible to ensure that the grouping of these branches is done without bugs and does not break anything in the already existing code. In order to avoid regressions, all branches developed by technical team members should be tested and OK prior to deployment.

At BAM, we manage these 7 standards because they guarantee the quality of the product code throughout the project and allow our customers to easily continue their mobile adventure after the departure of our teams. We recommend that each member of a mobile development team monitor and develop these indicators as needed. If you were interested in this article and you are wondering about the ideal team to form to develop a quality project, discover our 5 tips for choosing a development team.