Agility - From Theory to Practice at Melba

What is agility in the software world? Let's review its fundamental concepts (theory) and how we practice it at Melba

Published on 08/20/2021Sébastien Vassaux

What is agility in the software world? Let's go back to its fundamental concepts (theory) and how we practice it at Melba.

We discover how to better develop software through practice and by helping others to do so.
These experiences have led us to value

People and their interactions more than processes and tools

At Melba, we have worked hard to build a corporate culture that values ​​straightforward speaking and well-being. There is no better way to progress on the subject than to confront the theory of the Radial Candor book with its daily practice in the business environment.

To exercise agility, we rely heavily on the scrum framework. The scrum is a working environment that promotes communication. Being a scrum fan is therefore being a communication fan! This explanation helps defuse the frustration related to bad agility practices.

At Melba we have many processes and tools that make everyday work easier. However, we detach ourselves from it as soon as we encounter justified human constraints. The processes and tools are at our service, they save time, do not have to think of all the details because of automation.

Operational software more than exhaustive documentation

Let's say it clearly: we are very proud of our data. But it has no utility on its own, it serves to guarantee the stability of our software.

It has the role of spec : we write functional documentation for our frontend and API documentation for our backend.

We also write a lot of pseudo functional tests that allow us to clarify the behavior expected by our API. Almost 100% functional coverage has been achieved.

Does it take time? Yes. Does it make a difference? Yes, definitely: there is almost never any inconsistency, misunderstanding, regression, bugs. Everything is fluid. The software is operational.

Collaboration with clients more than contractual negotiation

We clearly build our tool with customer feedback. We have already discussed it extensively in this article .

Adapting to change more than following a plan

At Melba, we are lean at the core, and that makes us agile. We do not push things blindly on the market but rather look for feedbacks and integrate key learnings in our development process.

To fully understand what that means, I recommend reading The Gold Mine.

Several examples illustrate this:

  • Our roadmap is not fixed, it evolves frequently (it is never completely turned upside down, we have convictions and a little experience which makes it possible to avoid monumental errors)
  • We prepare a backlog 2/3 weeks in advance, we don't have a backlog filled with 200 tickets all ready . The opposite would amount to storing added value in the middle of the production cycle, and inventory is an enemy of lean .
We recognize the value of the second elements, but favor the first.

Find this on the Agile manifesto website:

Manifeste pour le développement Agile de logiciels

Nous découvrons comment mieux développer des logiciels par la pratique et en aidant les autres à le faire.

A team at the top

Want to learn and make an impact?

The underlying principles

Our highest priority is customer satisfaction by quickly and consistently delivering high value added features.

Our work is based on user studies. We are always concerned with a high ROI and an optimal UX / UI.

We put into production almost once per person per day with peaks of 2 releases per day per person..

Be positive about changing needs, even late in the project. Agile processes exploit change to give the customer a competitive advantage.

Our project is our company. It is agile, not only in software development for that matter. In our marketing and sales practice we follow the same principles. In any event, changes are welcome, dealing with them and a sign of lucidity. It is obviously easier to embrace them than to sacrifice an investment. Hence the need to carefully study the need and not to invest too early.

Frequently deliver working software with cycles of a few weeks to a few months and a preference for the shorter ones.

We work in a 2-week sprint, that sometimes changes, but we deliver continuously.

Users or their representatives and developers must work together on a daily basis throughout the project.

Our team has a product culture and an agile culture. Communication is simple and recurring. We communicate daily and because the sprints are used to reduce dispersions, we remove most of the doubts in our backlog refinement and planning poker period.

Carry out projects with motivated people. Provide them with the environment and support they need and trust them to achieve the goals set.

Our team deploys extremely positive energy. It is a talented team and the talents attach great importance to clear objectives and optimal material working conditions. Want to learn more? Read First, Break all the rules .

The easiest and most effective method of conveying information to and within the development team is face-to-face dialogue.

As soon as an exchange gets longer, we call each other. As soon as a telephone discussion becomes complicated, we program a face-to-face meeting.

Operational software is the primary measure of progress.

Operational does not only mean bug free but also usable. Hence the importance given to UX in our processes. The routes are simplified as much as possible. Many customers prefer us to more functionally richer solutions, simply because our tool is operational = usable.

Agile processes encourage a sustainable pace of development. Together, the sponsors, developers and users should be able to maintain a constant pace indefinitely.

We do not rush, even if it goes very quickly. We advance by successive iterations, in a comfortable and exciting pace.

Continued attention to technical excellence and good design strengthens agility.

"Build quality into the product", dixit The Gold Mine. Excellence at all levels ensures that you don't have to go back 3 times to a poorly designed project.

Simplicity - the art of minimizing the amount of unnecessary work - is essential.

Excellence is also simplicity. In particular, technical delusions are prohibited. The whole team is made aware of a good ROI.

The best architectures, specifications, and designs emerge from self-organizing teams.

On our scale it is quite simple. We can't wait to have multiple teams and experience agility at scale.

At regular intervals, the team thinks about ways to become more efficient, then adjusts and modifies their behavior accordingly.

At the end of the sprint, we are retrospective which allows us to understand what worked, what needs to be improved and we give ourselves a to do list. We frequently vary the formats so as not to tire the team and bring out new things.