About the struggle to introduce Scrum to an organization where top leadership positions change frequently.

I wrote this article reflecting on my time as Product Manager in AIESEC where I was responsible for product development and the agile development processes.

Let me first start by giving you some context: AIESEC believes in giving youth leadership experiences to develop leadership competencies in them so they become better future leaders.

As such, all leadership positions are held by young people (Yes, even the CEO) who usually are not formally trained in the job they do and have little experience. Oh, and also they change every year. I started in September of 2018 and finished in August 2019. Then my successor stepped up and now continues my role.

Scrum’s success relies heavily on the buy-in from key stakeholders and senior leadership. This buy-in is hard to generate when these people change every year and the person who initially made the decision and the commitment is not there anymore. Below, you will find a path of conscious and unconscious decisions that led to us introducing Scrum over a span of 3 years.

2016/2017

When the IT team at that time (CTO and Product Manager) started, they had inherited a vendor for AIESEC’s Global Information System (the sum of all our platforms plus the API powering them). The status quo at that time was infrequent planning meetings where project requirements were delivered to the vendor followed up by irregular status meetings and a history of not meeting deadlines. A few weeks after that the vendor got insolvent. This gave the IT team the opportunity to find a new vendor and to set up all management practices from 0. They went with Commutatus (based in Chennai, India), basically copying the previous vendor contract and went with the process suggested by the new vendor. They got a team of 5 development team members, including the designer, backend and frontend.

Learning from the previous bad experiences, AIESEC was taking an active role in the development process, by gaining access to Jira, and essentially growing into the role of the product owner. Sprint duration was set at 1 week and AIESEC and Commutatus agreed on regular status meetings with the team leader of the development team to define product requirements. Another regular meeting was set with the CEO of Commutatus to discuss process improvements.

In India, the development team would meet weekly to conduct sprint planning and break it down into the tickets. They would conduct daily meetings and the sprint would conclude Friday evening. All done work was pushed to a staging environment for AIESEC to verify. The next sprint would automatically start on Monday where work not done in the previous sprint would usually continue.

Please note that the formal roles and events of Scrum (Product Owner, Development Team, Sprint Planning, etc…) are not capitalized in this section, as AIESEC was neither using nor planning to use Scrum at that time.

AIESEC was using a mixture of waterfall and agile where requirements were loosely defined based on the organizational roadmap for one year and would emerge with more clarity and detail on a weekly basis. As I was not part of the team at that time, I cannot comment on the effectiveness of the process at the time or the success of the delivered projects.

2017/2018

This is the year that I joined the global office of AIESEC. The IT team grew by one Product Manager. At our planning, we decided to prioritize two projects that required us to launch new platforms. We also decided to take on the refresh of another platform. And then, we took the decision to launch all of these platforms within 6 months. Ouch. This was because 6 months later was when we would have our annual gathering of presidents of all of AIESEC’s national branches. This is the most important touch-points to generate buy-in with all our subsidiaries, building momentum for any change driven within the organization.

We relied heavily on design sprints (read here how we split up the design sprint to be conducted with a virtual team, without having to block off an entire week), sometimes running up to 4 of them simultaneously each week. This allowed us to come up with solutions, wireframes, and user flows rapidly fast, feeding the development team with complete requirements at the right pace. By implementing user feedback, we learned to introduce iterations to our product backlogs.

These new processes were all still easy to implement since they did not affect any of the stakeholders. Projects were still picked from the organization's roadmap, a deadline was set and work was done within the goal to deliver on that deadline. This is where the project began.

What we delivered were working products riddled with bugs and performance issues that theoretically fulfilled the goal for which it was conceived. Our engagement metrics showed that they failed to deliver on that. This, however, was not what our performance as measured upon. Our projects were celebrated successes!

In the second half of that 1-year tenure, more problems emerged. Other responsibilities of AIESEC’s Product Managers were mandating them to travel and generally occupied them with different duties. This resulted in weekly meetings not happening regularly and the product backlog not being kept in shape. We subsequently started to fail deadlines for features and our ability to identify and fix bugs in a timely manner declined.

2018/2019

I had decided to continue one more year in the organization, this time as a leader of Product Managers. We knew we needed to change things to tackle all the problems we experienced before. At the same time the organization, motivated by our previous success to deliver, mandated more projects to us. Also, our organization's headquarters had just moved from Rotterdam to Montreal, introducing a 9 hour time difference between us and our development team.

At the beginning of our year we decided to implement the following changes to improve our process:

• features were delayed because they did not meet expectations when handed over. We introduced an on-boarding of the development team to the sprint goal so they knew why they were doing what they were doing and allowed them to take small product decisions independently.
• an internal feature presentation caught issues with features during the sprint and allowed the developer to improve before the sprint would conclude.
• increasing sprint length to two weeks to allow for more uninterrupted time to deliver the work.

By then, we already had a good amount of Scrum elements implemented:

• Sprint Planning with Sprint Goal
• Daily Scrums
• Sprint Reviews
• Scrum Master (project manager)
• 2 teams working on the same product backlog

However, there were still some things that were amiss.

• No Retrospective
• Product Owners joined neither Sprint Planning nor Sprint Review
• No presentation of done work to stakeholders
• Sprint Review did not happen at the end of the sprint
• Multiple Product Owners working the same Product Backlog

At that time we did not know that this was a problem and would lead to the following dysfunctions within the next 6 months:

• impediments were left to the project manager to solve alone. Improvements were not created in collaboration with the development team, hence there was no buy-in
• Sprint Goals were not clearly set and did not give guidance to developers
• improvements suggested in the Sprint Review were always treated as a high priority without selecting any tradeoff, which led to features not finishing in the initial timeline
• Product Owners would give conflicting directions as they were not fully aware of each other’s Product Backlog items.

Hence, we knew that we needed to change things again. Having recently acquired my Professional Scrum Certification we did not want to repeat the same mistakes again and aspired to implement Scrum by the book.

Our biggest challenge was the unavailability of the Product Owners for Backlog Grooming, Sprint Planning or Sprint Review, due to both the time difference and the busy schedule that came with our role on AIESEC International. To solve this we took the bold decision to make two members of the development team Product Owners working with their own Scrum teams working off the same Product Backlog. They would be placed in our Montreal office, allowing them to work closely together with AIESEC to fully understand and breath our business strategy. Us, who previously held the role of Product Owner would act as Stakeholders.

After having implemented these changes and running with them for another 6 months, I can confirm that they did lead to an improvement, but not necessarily as much as we had hoped for. In my last months I vowed to pick my last battle, which was to ensure ensure that my successor's Product Backlog would be less defined by projects that are set on a 6 months or one year basis but to allow for priorities and features to emerge on an ongoing basis as we know more about the market place we operate in, our users and how the product fits inside.

Having been 3 months in my new role as Product Manager in Fave and learning how different Product Management and Scrum can be with having developers on-site, I know that the next step for AIESEC will be to bring developers into their office in Canada and thus bridge the communication gap between the Product Managers and the developers.

Do you have similar struggles with Scrum in your organization? Contact me and we can look into how we can collaborate to solve them!