The Framework for Any Methodology Transformation
A set of guidelines a tips for transforming teams in Agile
Hey, fellow Leader 🚀,
I am Artur and welcome to my weekly newsletter. I am focusing on topics like Project Management, Innovation, Leadership, and a bit of Entrepreneurship. I am always open to suggestions for new topics. Feel free to reach me on Substack and share my newsletter if it helps you in any way.
While conversing about transforming teams into Kanban, I realized some of the methods and tips are valid for many more transformations apart from Kanban. Any big shift in methodology requires a set of steps to ease the team into a successful implementation of the target solution. Here are some coffee tips for making that transformation a bit more smoother.
Training
Yes, is very obvious right? The problem is that when someone starts to have successful implementations under their belt, some of these basic notions tend to be considered standard and an assumed pre-requisite. Is important to provide the team with training on the methodology to be implemented. This will fix some wrong impressions, promote expert discussion, and improve the overall understanding of the definitions that will pop up in the discussions.
For example, one of my Kanban implementations where continuously being challenged with questions from the team’s technical leader. Being challenged is OK, however, while digging further into the questions and notions, he was continuously mixing Scrum practices with Kanban. This is because he never had training in Kanban, so his feedback is always in the light of Scrum, which in my point of view, where completely misaligned with the methodology. In these cases, the Project Manager will become an Agile Coach by trade. Is inevitable.
Team buy-in
Some teams accept change with open arms, while others refuse in the deepest form possible. The transformation is for the team, and the team needs to see the added value. There is no point in implementing a crystal, bulletproof, scrum practice on a team that sees no value on it. Some might argue the team needs to be convinced. I might argue the team and the Leader need to arrive at a common ground, where is clear what kind of transformation will benefit the team.
On one of my previous projects, a Kanban transformation was cut in half, simply because the team was not buying the full methodology. It is OK since we managed to fulfill the majority of the objectives: Improve the visibility of the priorities and improve the visibility of the work that was being done. The last step was to put in place the metrics, which ended up defining the moments of replenishment and done on the team’s workflow. That’s it. It was not the shiniest Kanban transformation under my belt, but it worked and is the most important.
Another trick is to make the people who are more resistant to change into the transformative process. Since they will be the team members who will object to the majority of the topics, it’s better to address their concerns and transfer them to the heart of the change. That way they can see why we are doing things like that, and increase their change ownership.
Team Engagement
A disaster scenario is to have a team without sharing feedback and not owning the team’s processes and changes. I had retrospective meetings which weren’t meetings but a podcast of me talking about every issue and point. This is not desirable, at all. It can be even a symptom of an issue inside the team.
A strategy to increase team engagement is to ask informally, and individually, their opinions about the current state of affairs. The goal is just to have a picture of what are the main concerns and improvement points the team might have. Also, is highly important to get positives as well. Sometimes we focus so much on the negatives, that if we don’t shed light on the positives we end up not valuing them and we risk losing them.
Once I have a better picture, I organize a dedicated retrospective call where I ask the main topics to be sent to me in advance by email or chat. While chatting informally with the team, and having requested the topics before the meeting, it will trigger thought processes individually and will end up by having people putting front their concerns and ideas.
The retrospective meetings must welcome ideas and shed them in a good light. Otherwise, we will have an empty silent room without useful feedback.
Having the right tools
This might be one of the biggest problems. Depending on the organizations we might be stuck on pre-approved tool chains and software. I have been a victim of these in the past. Once I was implementing a Kanban change, and the Jira’s administrators hid the Definition of Ready, Acceptance Criteria, and Definition of Done fields from the tickets’ form. For anyone doing any form of Agile implementation, these fields are crucial to understanding the ticket’s scope readiness.
The answer? Work with what you have. Comment on the ticket with the information by implementing a template to be used across the Jira tickets. Is it elegant? No. Does it work? Yes. Does it show the organization wants to be agile but doesn’t care if is done properly? Unfortunately, yes.
That’s it. If you find this post useful please share it with your friends or colleagues who might be interested in this topic. If you would like to see a different angle, suggest in the comments or send me a message on Substack.
Cheers,
Artur