This week has been a fascinating one, packed with suspense and speculation. I have supported a team that is transiting to Agile from a chaotic state and I came face to face with the challenges of embracing change within a team and at the leadership level. I have seldomly worked with this team, but it is the first time I am getting to understand their working process. It is a team comprised of 6 developers and a product owner. One of the developers doubles as a Scrum master and is the one pushing the team to embrace Agile. While there are a few baby steps that the team has made, they are still in the dark about what to expect and what to do. I had the following observations, which made me wonder how other teams experienced their transition to Agile.
Leadership
The “Scrum Master” has been tasked with streamlining the team and coaching them on the benefits of transiting to Agile. However, a caveat in this approach is that the leadership has a laid-back approach and is also pessimistic on whether there is any value coming out of the process. The team has been in existence for the last 5 months, and the leadership is yet to officially communicate to the team why they believe that they should go Agile. What happens to a team where they can clearly see that the Leadership is paying lip service to the process, but going contrary to what they are advocating for? There will be lackluster in the team and however much the Scrum Master works hard to help the team embrace Agile, it will be an exercise in futility. Because human beings naturally tend to be followers, the leadership has to be supportive of the process if they are to exceed. In his 2014 book, Accelerate, about Change Management, Dr. Kotter observes that Leadership involvement is necessary if real change is to happen and the value sustained so that things do not ultimately drift back to default status. This team needs the leadership to step up and back the efforts being made to transit to Scrum way of working.
Overachieving
While the leadership is skeptical of the process, the “Scrum Master” is an overachiever who is so zealous to get the process injected into the team. She has been busy having uncoordinated meetings with her team and shoving down their throats on what is Agile and what is not Agile. Interestingly, she gets mixed on her own facts and when asked about the claims, she has a standard answer “That is what we will do for now”. This has left the team frustrated and feeling hopeless about the situation. This is because the developers believe they have proper control of their workspace and understand what is needed of them.
The team members have occasionally stopped me at the coffee machine or in the corridors to ask whether “this and that” is Scrum practice or not. While in some situations I have been able to answer them, in most cases I think their concerns are genuine and I always end up telling them that Scrum by definition is a Guide and should not be used as a metric standard for working in a team. For example, if I am driving from Copenhagen to Hamburg, I know that the GPS will guide me through the most convenient route, but I have to define the criteria for convenience. But this in itself is just a guide. I could drive from Copenhagen to Odense on the highway, and then drive along the countryside for the next 30Km, drive from small cities to cities in the next 50Km and then round it up again on the highway. What matters is does the route suit me and my passengers? Are we in a hurry to come to the destination or we would like to explore the routes as we drive? Are we willing to have some stop-overs along the routes to drop or pick someone? These specifications will define the parameters for my “convenience” criteria. Similarly, when starting out on Scrum/Agile, the Scrum Master does not have to whip the team to abide by all the practices that are embodied in Scrum. Start with small practices, ensure transparency in the process and importantly help the team to understand WHY they are doing something. Surely, not all practices will be suitable for the team from the beginning, especially the ceremonies. So, allow them to Inspect the processes and Adapt as they go along the way.
When starting on Scrum, I advise teams to take a stance of zero heroism. No matter how much a team member understands Scrum, the ultimate reason of engaging the team is to work collaboratively and keep on improving the process at a sustainable pace and continuously satisfy the stakeholders. This is analogous to being a top scorer in a football team that is under threat of being relegated from the league. It is then better not to score a goal for a whole season, but support your team to avoid being relegated from the league. Being a top scorer and the team is in relegation zone, earns the team no credit. Zero heroism!!
How did you transit to Agile and which practices were difficult for you to embrace? Have you finally embraced them in your processes and how do you handle lack-lusture leadership and/or overachieving Scrum masters? Please share your thoughts and comments
Project Management 