Poutine makes your agile organization perfect!

About this Publication

For those of you who are new to our national dish, the “poutine,” is much more complex than it lets on. It consists of three ingredients such as potatoes, cheese, and gravy sauce. To my surprise, most people underestimate the power of these three simple and humble ingredients layered with their various subtleties of techniques and flavors.

Organizational changes are like poutines! Simple and straightforward from the outside and layered and complex from the inside. Like poutines, changing any delicate aspect of its technique or flavor may bring disastrous results. In our case, what we thought would be a simple change of sauce for our poutine became one of the most important learning opportunities in our transformational journeys. This is the story of us playing with the organizational poutine recipe over and over again as we went through various organizational transformations.

Bon Appetite.

1.       CONTEXT

Several years ago, we were a growing European based company with a very successful e-commerce product. We were growing fast and had little time to reflect on how to organize. As a European company, we envisioned entering the North American market and to achieve that, we merged with a Canadian company in 2012. The opportunity was great — new development teams, sales, support, IT and HR. What could possibly go wrong?

The merger put a hot spotlight on how we worked together: the roles and responsibilities of each group (Europe vs. North America). It further shone that spotlight on the challenges of releasing a single product across both our current and new locations. The spotlight revealed the challenges arising from different approaches to architecture, different approaches in development processes and practices, and different approaches in a variety of other processes. As a result, releasing our product soon became challenging.

Like our “poutine,” the organization could no longer ignore the rich aspects of each layer that constitutes a more mature organization. Such layers could be identified as the culture, mindset, people, technologies, politics, power, structure, etc. A small change in any of these layers could throw the whole “recipe” off just like our precious “poutine.” Organizational change is made up of these important elements, and all require special attention if we want the right outcome.

The secret to “poutine” is in the cheese. This is where most people fail when attempting to recreate the dish. While we appreciate the numerous combinations concocted since its initial inception, nothing beats the original. The particularity of the cheese is its high tolerance to heat, meaning that it does not melt at the contact of the hot ingredients, both the potatoes and sauce. The texture of the cheese also provides an excellent feeling and marries well with the other elements.

Everyone involved during the transformation strongly believed that we had all the right ingredients to succeed in this change. Having all ingredients and recipes is vital when faced with such a broad change, because the adversities are all stacked against you. However, we all know regardless of the right ingredients, change is hard. Transformation is not like your grocery shopping list. What makes it different is the love and empathy that drive the transformation, which makes change successful or not. When you bake in empathy as part of your transformation, you do not need to add any fancy toppings to your poutine. Sometime the classic one just works the best! The point of this delicious metaphor is that while the right ingredients make a world of difference, the journey does not end here.

This is our change story and the lessons learned from both our successes and our failures. From our experience we learned the following:

  • Plan for the unplanned
  • Don’t underestimate the power of emotions (culture)
  • Communicate and communicate again
  • Timing is important
  • Enablement (of teams/individuals) is key.


As previously stated, our company was on a fast track, grabbing all the right attention. As part of the strategy to grow market share and enhance our knowledge of commerce, our company merged with a North American software firm. This merger was the start of many changes and the focus of this paper.

As the two companies began to know each other, it became apparent that integrating would not come as easily as the leadership team believed. Some of the symptoms that could be observed were:

  • Entrenchment: people were holding on to their roots and a sense of “us vs. them” formed.
  • Devaluation: feeling like an outsourced team with little input into how decisions were made. Two independent companies were working together on the same product stack while not having a clear and agreed set of processes, roles and responsibilities. The integration between these two teams was hard and time-consuming.
  • Fear: lack of trust and fearful for their future.


After a few months and an increasing need to address this conflict, a personal approach was chosen to incorporate the principles of the parent company. A member of the leadership team moved to Montreal from Europe in an effort to show everyone the dedication they had to the newly formed relationship and resolve as best they could the symptoms observed.

Our immediate next step was how do we get the teams from both locations to work together? Our investigation started by examining which process could provide the necessary support to organize our software development departments. The answer came in the form of Scaled Agile Framework (SAFe). SAFe was chosen because it provided the missing links that were becoming apparent between the different groups. The most important benefit of SAFe for us was how it addressed issues that were relevant to us. Its structure, its definition of roles and responsibilities promised to work for a global company such as ours. Also, program management and release managers are particular examples that come to mind, which provided a much-needed “big picture” view.

While we make it look like this came easily, this decision came after extensive conversations and research executed by the newly minted team known as ACE (Agile Center for Excellence). In our “poutine” metaphor, the ACE Team would be the sauce, which covers the other two ingredients and also adds value over the entire dish (organization).

Aided by certified SAFe consultants, ACE took on the large task of getting every single person trained on this new method. While training was executed locally in each office for most teams, we had all locations come together to train as a group for Product. We brought all teams together to ensure everybody has the same understanding of the new processes, roles and responsibilities. More importantly, this expedited the storming phase for this new product team by having everyone in the same location.

ACE’s mandate also included the coaching of the different teams ensuring that the change was well digested and eliminated any major hurdles preventing progress. The composition of the ACE team included the following:

  • Scrum Master
  • Agile Coach
  • Release Train Engineer
  • Program Manager


This team had a very good picture of how to execute the process and deliver our product at scale.

Now that everyone knew HOW to do it, we needed to start on WHAT to do. This came in the form of our very first PI planning session where all members of the organization come together under one roof to plan the next Potentially Shippable Increment (PSI) planning for the next 3-4 months. This activity was very exciting for everyone since all members travelled to Poland to be under one roof while planning our development activities.

We wish we could tell you that it went marvelously well and without any issues but this exercise revealed numerous challenges and in big part due to cultural differences. An example, picture 200 people from 4 different geographical locations (Germany, England, Poland and Canada) coming together with little knowledge of how they would work together. Each group was used to their practices, their tools and approaches and to some extent believed the other group was doing it wrong.

To this day, the definitive bonus of this “big room” planning exercise came from the newly created relationships that were formed when all our teams came together. People still remember the excitement of this activity and how it provided people the ability to solve problems and address dependencies “Just in Time.”

As both sides of company began to regard us as objective and trusted coaches, we became the catalyst to coach individuals and teams to help them to establish a common practice to develop, test and release. As we did not lead by authority, we were able to engage with people especially the ones who were resistant to the change or impacted the most. From this we learned 4 lessons:

Lesson no. 1: Have a dedicated team to introduce the change. Our first learning at this stage is the value of having a dedicated team to introduce and implement change. Ideally you would want to ensure continuity long after the transformation and apply an improvement model according to Agile values. However, if this is not possible in your context then you could create a non-permanent team in your organization, meaning that members of the team could come from different areas and could disband once your transformation has “stabilized.” As long as this team can focus and dedicate to the change during its inception, implementation and conclusion, it will be really beneficial. In our case, we were lucky to have a dedicated team right from the beginning. This gave us great insight into the challenges of the organization.

Lesson no. 2: Implement guardrails for the process and responsibilities. This helped people to relate to the new big picture. This was very helpful because we were coming from a very “loose” startup structure where people picked up any responsibilities they liked and created chaotic situations at times. Not everyone can be responsible.

Lesson no. 3: Avoid relying solely on roles of power to be responsible to keep change activities progressing. We learned this the hard way because our leaders became bogged down by many competing priorities and were not available to keep the “change drums” beating. Like our poutine, they left us with only parts of the necessary ingredients for this to take shape. Favor an approach that leads to empowerment and diversity within each area. We relied heavily on local influencers (non-managers) to understand the challenges more effectively. It is more effective because each and every person is enabled to multiply these changes in their direct area.

Lesson no. 4: Overcommunicate the organization’s intent. This requires openness across the board to be able to communicate, refine, refine and refine. For example, if you limit the communication to your organization by means of “Townhall” or “All-hands” delivery, this could lead to unspoken anxiety, fear or frustrations because this information was not digested accordingly to their context (aka daily lives or direct teams).


One of our greatest challenges working with distributed teams was the component dependencies that each team were responsible for. SAFe attempts to address this with what is known as the “Systems Team.”

Using our “poutine,” the systems team may be much like the potatoes. Anyone unfamiliar with the dish would immediately dismiss the importance of the potato, and simply “just grab any potato and fry them up.” The challenge becomes a question of consistency. We do not want a potato soup with cheese, because the potato happens to be too soft and breaks up.

Much like the potatoes, the “Systems Team” holds things together and is responsible for managing incoming functional code and ensuring its integration within the overall product. This also meant that the team validated dependencies by running tests and packaged once everything was green. Just like the potato in the “poutine,” the “Systems Team” was our main ingredient to a successful delivery outcome.


It quickly became apparent the systems team was a bottleneck and was not able to keep up with the increasing level of integration points and quality issues. At first, the organization felt we needed to improve on how we identified dependencies so that we would minimize the impact on the “Systems Team.” The issue with this line of thinking was the fundamental underlying problem of software development: it is complex, and unforeseen issues emerge as we build the product. Nevertheless, we continued by redoubling our efforts to improve communication between the “Systems Team” and delivery teams. This path did not lead to significant improvement at the time, but in hindsight, it led us to make better decisions for the future, which we will cover a bit later.

It took two more PI planning ceremonies before we finally decided to overhaul the process we were using. In total, from the preparation, rollout, and execution, we officially used SAFe for a little under two years.

Here is what SAFe taught us and we believe that without it, we could not have achieved the next steps of our transformation.

  • Team alignment
  • Bounded responsibilities
  • Product planning
  • Dependency management

Lesson no. 5: Avoid any structure or process which implements an “over the fence” mechanism. An important element we learned a while back was, “show the system to itself.” Bringing forward our collective consciousness of how we operated as an organization and learning about our key strengths, pains or improvement opportunities was the most vital aspect of this whole experience. An example of this over the fence mechanism are “gates,” where validation is done by another team and requires work to be completed before doing any work by the “gate keeping” team.

Lesson no. 6: Do not fail to recognize the importance of accountability within each team. Our biggest struggle with our experience with SAFe came back to this complex yet simple issue, that centralization created an Engineering culture clash, and the desire to be “right” led to toxic behaviors (e.g., blame, defensiveness, entrenchment). For example, the systems team came under fire for not having delivered specific parts, so they created a tight circle around themselves, claiming that any distraction was preventing them from achieving their goal.

Lesson no.7: You cannot simply put any practices or process on top of any software architecture. Avoid the cookie-cutting approach. Our tightly coupled architecture at that time (no longer an issue with our microservice solution) put a lot of pressure on the system team.


Based on observations and repeated frustrations from development teams including the “Systems Team,” we chose to get to work on crafting our very own structure. The ACE team, through various research and experiences, gathered information and documented a proposal for the organization to adopt. This proposal was coupled with technical and architectural decisions that were taken in parallel, the most important one being the decoupling of key parts of our product in order to reduce the total number of dependencies.

This work helped us organize and restructure the layout of the teams and further improved their ability to deliver. It became clear that the process that we wanted to adopt contained pieces from multiple sources. This “cookie cutting” approach left us with the best (what we liked) of SAFe and we took other practices we knew to be useful to create our very own “recipe.”

The outcome of the exercise was:

  • Sponsored organizational change by the leadership team
  • New team structure that matches the newly split product
  • Process guidance documented centrally on the wiki
  • Documented roles and responsibilities
  • Focus on empowering teams for faster implementation/delivery

This new restructuring took on the theme of “Innovation, Agility, and Speed.” The slogan was meant to inspire and empower people through the change because we had all experienced several in a very short time (Merging two companies, SAFe). Our main goal was to transform our organization to foster innovation, agility and deliver at speed.

One lesson that we learned over time is the importance of communication at such times. A small confession with respect to communications, even though we significantly improved, we are still struggling with this aspect and pushing to get better. What we observed through the changes described above is that we often took for granted the time at which we communicated key information to our organization. In our view, the biggest success factor is the strength of your message and how often you deliver it.

During our implementation of the new process, “Innovation, Agility, and Speed,” the message was driven home initially by our leadership team. We wanted to give it the necessary weight, and for people to pay attention. We, therefore, needed to use our best influencers. The ACE team had also done their homework, during a workshop we dissected the organization and identified the people who would be likely detractors or contributors to this change. The goal was to approach these individuals and ensure that they would support the upcoming message and drive home the right attitude in their circles.

John P. Kotter’s Leading Change [1] is one of the more frequently cited books on change management. We chose to introduce Kotter’s work at this stage because one explicit factor was becoming clear to the ACE Team during our many restructuring experiences, we were not very good at change management. We had the right ideas and executed well on the different activities but treated our change as an event. As we mentioned earlier, we had worked to identify key influencers but failed to recognize that this is a process and were not organized to support it over time.

The concept of the “Guiding Coalition” was occupied by our leadership team and since they had many other competing priorities, each member could not focus on the ins and outs of the change. While leadership had a pivotal role and intervened in many occasions, the problem was we did not involve different people of our software development teams and relied too heavily on the hierarchal power of our leaders. Emotions were flying high at this point. We had just come out of a big change and now restructuring to accommodate for some gaps. In the process, people were shuffled and inherited, voluntarily or not, additional responsibilities.

Lessons no. 8: Involve a wide array of roles. Our mistake was the application of a top-down approach, even though we advocate a flatter structure it would seem that certain types of involvement are harder to digest.

Lesson no. 9: Delegate. Enablement is crucial and if people are put in the middle of it how else are they supposed to feel? We are not talking about pushing the problem forward but giving clear and explicit expectations for individuals or groups to achieve.

Lesson no. 10: Resistance always exists. How naïve could we be? Regardless of any type of change. This latest change was meant to feel good and planned on making a huge leap forward. Our “poutine” fell apart as we did not anticipate resistance yet again. Consider resistance even though, if you have a perfect plan.


After a few months, the company was enjoying its newfound freedom of the new structure of speed, innovation, and agility. We were getting comfortable with our change and what they mean for us. Everybody learned or was still learning how we need to collaborate with each other. Suddenly, we were acquired by a global giant. The transforming company was now becoming part of one of the largest software vendors in the world. The ACE team was about to go through its own transformation, because the organization was going through yet another change and we needed to conform with the shifting strategy (i.e., how can we help the new strategy and transformation) The news shocked a lot of our colleagues; the main point of contention was our identity. What was going to happen to our nimble organization?

Mr. Kotter has extensive experience in this field, and we would like to share one important quote [2] from his work with XLR8 about implementing an entrepreneurial structure in an existing organizational hierarchy: “Here is the bad news. How many organizations have succeeded in doing that? About 0.001% […].” This is not meant to discourage but rather, create a sense of the urgency and importance of such a change. We believe in change management and how effective and rewarding it can be. When applied continuously and with an executive sponsor(s) who can support the new initiatives and value coaching people to enable the greater operational excellence you defy the odds.

We are hopeful and grateful for the opportunity to work with two different things we love: The great people and an amazing product.


Our organization, roles, responsibilities are like ingredients. Our process as our new recipe. Our empathy and care as the secret sauce of our transformation. Then, our poutine started coming together. Having such an analogy in mind for every change was our perfect balance.

The transformation is a never-stopping journey. The moment you finish your project, you can see more to start. This whole journey better prepared us for the future that was ahead and gave many people the necessary conviction to pursue their path.

Our learnings were numerous and often blurred by many layers which left us with a sweet and sour taste at times.

  • Here is the list we mentioned earlier:
  • Plan for the unplanned
  • Don’t underestimate the power of emotions (culture)
  • Communicate and communicate again
  • Timing is important
  • Enablement (of teams/individuals) is key.


We still struggle with new lessons but have taken measures to minimize the impact of previous ones. If an organization is too quick to change, meaning that we do not have time for proper change management, then like all good poutines, organizations may often become a “hot mess” of politics and roadblocks when it comes to transforming itself. The soft and fluffy stuff of social interaction matters.

We believe that we still have not extracted all the knowledge from these past experiences and have yet to be surprised by how they could even help us today. The past is quickly forgotten and quite understandable since our flavors are so mixed and new.

As long as we will remain involved, our mission will always be the same, create the most desirable poutine in the world.

7.       Acknowledgment

We would like to share our gratitude to Steve Adolph who was our shepherd throughout this experience report and guided us with very great insight. We enjoyed working with you Steve. Last but not least, we would like to thank XP 2019 for accepting our experience report and allowing us for sharing this firsthand experience with our community.



[1] Kotter, J. P. (1996). Leading change. Boston, Mass, Harvard Business School Press.

[2] Kotter, J. P. video, Accelerate,

About the Author

No bio currently available.

No bio currently available.