Interview with Maël Rieussec, President of Agile Montreal
The Homeric team had the chance to meet with Maël Rieussec, President of Agile Montreal.
Thank you, Maël, for meeting us!
Could you tell us more about yourself and your journey? Who are you, and what do you do?
I have more than twenty years of experience in IT, with a Bachelor's degree in computer science from UQAM. I started my career as a programmer, then began a transition to agility in 2008 with the role of Scrum Master. Since then, I have supported teams of different sizes, in different business areas and at different management levels.
I remember my first experience with an agile transformation, back in 2008. We were lucky to have an experienced coach, Alain Chaput, who was able to guide us successfully in this adventure. He showed me the benefits of this way of thinking. Everything resonated a lot with me. I thought it was “common sense”. Above all, this is what got me hooked on agility.
I then carried the dual role of Developer/Scrum Master, but quickly realized that I had to choose between the 2, because the levels of interaction and areas of interest are different. I was known to have a good human contact, in addition to being good at simplifying complex issues. I was also recognized for my ability to facilitate communication between business people and technical teams. This led me to choose agility for the next phase of my career. I self trained a lot and ended up finding the Agile Community of Montreal. I started by attending their events, then got involved as a member of the Board of Directors in 2014, and now as President since 2021.
Tell us more about Agile Montreal and your mission?
Agile Montreal is an NPO that has exists since 2011 and whose mission is to promote agility in the greater Montreal area. We offer networking events, several conferences per month, a mentoring program for people looking for support, etc. We are well known for our signature events (Agile Tour, Devops Day, Agile Open, Spark the Change, etc.). Another important component, Agile Montreal supports the development of communities of practice in relation to agility. If a new community needs a structure, tools, visibility, etc., they can approach us, and we will support them the best we can in their implementation and development.
You got into agility in 2008. Things were different back then. Can you tell us about the differences between now and then?
The biggest difference is that today, everyone is talking about agility, but without necessarily understanding what it is really about. Many companies are trying to follow ready-made recipes and bring them to scale. It almost became a management and/or delivery method, without really understanding the why and the values behind it.
Personally, I like to begin the relationship with the people I coach with a discussion around values and the “why”. I ask them, “Why do you want to be agile? What are you trying to fix? Because agility might not be the right solution for you, in your current context. And it’s fine!”.
I also try to be pragmatic, even within the community. There are diehard agilists who consider everything else as the devil or as outdated. But it’s wrong. Each context is unique. Hence the need to be well advised and accompanied.
You have coached many teams throughout your career. What issues do you see most frequently?
I have found that the most important problems are rarely present at the team level. We can quickly deploy a simple and effective collaboration mechanism within teams. The most important thing there is to put in place a good continuous improvement process, to ensure the teams improve efficently over time.
On the other hand, during agile transformations, I observed a lot of resistance coming from other spheres of organizations. For example, on the sales side (Editor's note: in a software service sales context). If sales teams don't understand agile properly, they will struggle to efficiently communicate the benefits of this approach. Salespeople will sign deals that aren't aligned with how teams operate. This means that from day 1, there will be misalignment with the client, which creates dissatisfaction and frustration on both sides.
Another example: Budget planning. A company that plans budgets over 2 years, over 5 years, while teams are asked to continuously inspect their work to potentially switch directions. We cannot function efficiently and comfortably in such environment.
When organizations are not agile in their fundamentals, but still want their teams to work in an agile way, it creates a clash. To work efficiently at the team level, agility must be understood and accepted beyond the teams.
You’re saying that several companies are implementing agile practices, but without being agile. Can you elaborate?
I can find out quickly, by paying attention to how they communicate. I see if there are concepts that are not mastered. For example, adapting to change, delivering value, etc. You take the 4 values of the agile manifesto, or the 12 underlying principles, and you realize quickly that they are far from it. Typical case, they take a BRD (Business Requirement Document) and they try to split it, so it fits into tickets. And, "that's it, we're agile because we do Daily Scrums, and we have Jira tickets”.
For me, agility means having the customer at the center of all your thoughts and all your decisions. You make sure that each of your activities creates value for the customer. It shouldn’t be to make your bosses happy, or for profitability. Obviously, profitability will remain an overarching goal, but it should be the result, not the starting point. First, take care of your teams, who will take care of your customers, who will pay for your product/services and generate your financial success. Not the other way around.
If companies want agility to generate results, they need to put in place a corporate culture based on trust. But it's not always easy to create or to maintain over time.
The context is also a strong factor. Agile methodologies, Scrum for example, are frameworks that apply well to product development, but not so much to project development. Without going into the debate of one vs. the other, it's true that it applies much better when you have a product, and the ability to experiment, get feedback and make it evolve with small increments. Agility is particularly adapted for complex domains, with many unknowns. You have to approach it with a scientific method. Make a hypothesis, run an experiment, look at the result, validate or invalidate the hypotheses, adapt the product and start again. This is called empiricism.
To build the Champlain Bridge, the parameters are known. It’s a complicated project, for sure, but there aren’t many unknowns. We know the laws of gravity, the price of materials, engineering rules have been established, etc. A waterfall approach is perfect for that. But if you plan to send a rocket to Mars, there are lots of unknowns. It’s highly preferable to use more agile, more iterative approaches to avoid having an enormous problem in the end.
As an organization, how can you know that you have built an agile culture that works?
You must find out if the teams (and not just the development teams!) have implemented an effective continuous improvement process. Are they trying to improve? Are they learning from their mistakes? In my opinion, this is where real agility is. If there is no continuous improvement process, there is no agility. It is fundamental. We must constantly ask ourselves what can we do today to avoid repeating the mistakes made yesterday, and deliver even more value to our customers, for the same time or the same budget.
Obviously, teams need to improve on the right things. The continuous improvement process of teams must be aligned with agile principles.
Delivery is one of the principles, but delivery without creating value for the customer or for the company does not make sense.
Another principle, communication. Be honest, transparent, talk to each other about the real things and don't let things escalate. Even if it is not fun to admit that we are late or that we have made a mistake, if we are honest and quickly raise flags, we can react and manage accordingly. Another important principle: it’s critical to create an environment of motivated individuals, people who understand what you are trying to accomplish, so that they are able to make the best possible decisions in the context and based on the information available.
Any last word?
There is a significant correlation between the agile maturity of organizations and the well-being of teams. The company must create a psychologically safe working environment, which starts with management, and that offers the possibility to all team members to openly say that they made a mistake without being considered incompetent or altering their image in the organization. That doesn't mean you can do anything and everything, but it's okay to make mistakes if you put continuous improvement processes in place to improve. This is how an organization can maximize the benefits of agility.
Thank you again Maël for sharing your experience with us! See you soon! 🙏😃
Interested in the topic of building strong, empowered product teams in a climate of trust ?
