Rebooting Agile – Key patterns to succeed

When Agile movement started roughly 15-16 years back, there were multiple reasons why Organizations latched on to it. One is the novelty factor. Agile was a new buzz word then and there was a sense of “Cool”ness associated in marketing yourself as an Agile Organization. There was a sense of “pride”. They took pride in the collaborative nature of Agile and that sold well to attract new talent. For the companies, who were majorly into IT Services, Agile became synonymous with Customer centricity. So, many reasons lead to the rise in Agile adoption during the first wave.

Once the excitement was over, then the companies began to think that Agile did not really help much. Except for the new language that Agile added like Scrum, Velocity, Story points, Backlogs etc. Many started seeing Agile was just a façade and that it was an old wine in the new bottle. Then came the blame game. They started saying “Agile doesn’t work well for us. It is too idealistic. Agile is too much of a disturbance for Developers. It is not people friendly. There are too many meetings in Agile. It is all about Micromanagement“.

However, some companies (and some teams) did not want to blame Agile and started reflecting on what lead to this failure. This requires true leadership. Is it the method to be blamed or the way it is practiced? Many in fact started realizing that Agile was not just a method. They started seeing the difference between Agile and Scrum, which was initially equated as the same. Largely, Agile is a philosophy and it is about *uncovering* better ways of working. It was more about achieving Agility rather than following a method called “Agile”. Most of the companies still do not realize this and hence are struggling with Agile. However, some of them who have realized that it is more about *ways of working*, they have hit a reboot button and they want to derive the benefits of organizational agility.

Here are the 5 key patterns to be considered when you are rebooting Agile.

  1. Be Outcome Driven: Most of the Agile transformation efforts didn’t yield results because there was too much focus on Scrum Events. Even that following only the mechanics of it rather than understanding the meaning of each of these events. In the outcome driven transformation, you will target the following business outcomes, which can be measured. Some of these outcomes are *Business Value, Transparency, Predictability, Adaptability, Quality and Productivity*. When you set goals of the transformation to achieve these, you will work towards creating and contextualizing practices to your needs rather than force-fitting the practices.
  2. Create an eco-system for systemic change: The first thing that needs to be recognized is that bringing Agility means bringing in “Change” and it would impact the whole organization and hence needs to be Systemic. It would be about shaking the people from their comfort zones. There should be sufficient space that needs to be created for this Systemic Change. Perhaps, there could be some drop in productivity for the first few months before it shoots up once people understand how to collaborate better to reduce systemic wastes. The communication on this aspect needs to be clear and trickle down to the lowest hierarchy in the organization. It is about creating a safe space for people to explore, experiment and enjoy the Change.
  3. Create Transformation MVCs: The transformation can be a really long journey that can face multiple hurdles on the way. It is important to create visible changes. These visible changes can be created as MVCs – Minimum Visible Changes. One of the MVCs that I often plan for in my transformations is to get the entire backlog managed in a Project Management tool like a JIRA or Azure DevOps tool. The DoD for the MVC can also be that all the team members are updating the tool on a regular basis with the reliable data. The MVC approach builds confidence in everybody and reassures that the Change is working despite the challenges.
  4. Make the progress of transformation visible: Just like you strive for transparency in your projects and programs, so the same goes with the transformation as well. Create the transformation stories (like user stories) and create a backlog of all these on JIRA-like tool. Keep updating the status of these stories so that anybody can be aware of the progress of transformation anytime. Ensure that you have regular catch up with all the key stakeholders where all the impediments for the transformations are raised and necessary solutions for the same are found.
  5. Get the larger part of organization to participate: Many people internally think that bringing Agility is Agile Coach’s job. So, they do not show enough initiative. Agile Coach may lead efforts to begin with but it should be the leadership and the teams that should show more initiative in the transformation. I usually start with identifying Agile champions who are genuinely interested in Agile and being part of an important initiative for the organization. I see to it that they drive the Change whereas the Agile Coach facilitates the entire process. Another simple example is the team members updating JIRA on a daily basis. It is not the prerogative of the Agile Coach to bring this discipline, it is really about all the team members understanding the need to do it. If the team wants to see the Change happen, they should also play a significant role in feeding the relevant information in the system.

I was part of one of the important leadership townhalls, when a Leader who was respected by the most said the following – “Delivery comes first. You need to put all your focus on that and only if you have time then you can focus on Agile and etc…”. There is really nothing wrong in emphasizing about delivery, but to separate that from Agility and to say that it was not very important was not a very wise thing to do. Agility is about Ways of working and Delivery is about the content. Both goes hand-in-hand. Leadership plays a significant role in making Agile work. When you are rebooting Agility, treat your transformation as an Agile project that models Agility.

What do you think?

Leave a Reply

What to read next