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 .

Find this on the Agile manifesto website:

The underlying principles

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..

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.

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

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.

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 .

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 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.

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

"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.

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

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

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.