When we first start the Agile journey, there are many things to account for, and it gets overwhelming at times. We do not know which items to focus on first, and the pressure keeps growing. Even after reading lots of materials and going through lots of training, it still feels that we are missing something and could have done things better.
One thing to remember, though - Agile transformation is an iterative process. You will never get things perfect from the first time. You learn from your mistakes and become better.
In this article, I would like to share some of my experiences, and hopefully, they will help you avoid similar mistakes on your journey.
Forming Agile teams is not enough
When we had just started our Agile journey, our primary focus was on forming Agile teams and the processes they would follow. We didn't think much about how those teams would interact or the organization structure beyond the team level. Moreover, there was no proper assessment of the technical readiness of the company to start operating in two-week delivery cycles. As a result, there was lots of frustration and unclarity in the new process. Even worse, we felt like we were doing waterfall in sprints.
Based on what I know now, one of the first things I would recommend is to think more about how you will scale the process in the future and connect all the dots. The bigger the company, the more critical this objective gets. Many companies decide to go with the SAFe framework as it offers a solution at the broader level, not just for the teams. Many other frameworks try to solve a similar problem too. Unfortunately, none of these frameworks are perfect. Before you pick one, think carefully about all the pros and cons of each.
Also, study your existing org structure and decide whether it conforms with upcoming changes; more importantly, what you will do if it doesn't. Companies are often structured around business, technology, or customer relationships as separate areas, which is not aligned well with a concept of cross-functional teams.
One more aspect to focus on is how much automation vs. manual steps you have in place within your value delivery process. While working in two-week cycles may sound like a great idea, make sure it makes sense for your current delivery model. In the early stage of the transformation, it may be more efficient to start with three or even four weeks depending on the situation.
Lack of clarity on value delivery workflow, roles, and responsibilities
Identifying the value delivery workflow process and its key players for each step is one more thing you want to do ASAP. Otherwise, you may end up like one of the companies I worked at - people were lost and lacking a clear picture of who does what at which point. You can't fix things that you don't understand.
Here are the three steps you need to follow.
Step #1. Have a workshop to create a visual representation of all the activites that need to happen from the moment the new feature gets requested until it's deployed to production. Tools like Mural or Miro are pretty helpful for this exercise. Such a task is much more straightforward for small companies and start-ups as you have fewer parties involved: typically, Agile teams would be the ones who talk to customers, develop the requested feature and deploy it to production. However, it gets more complex as the size of the company grows. You will need to account for the activities of PMO and finances people, security and compliance, marketing, etc. Also, there may be a centralized platform or enterprise architecture groups, which significantly affect teams' deliveries.
Step #2: as you have all the activities visualized and connected, identify roles and responsibilities for each step. For example, you should be clear on what the teams vs. the PMO are responsible for. If you have multiple teams working on the same product, clarify who is responsible for across-team coordination and dependency management. Furthermore, you want to discuss the responsibilities of people whose functions are not defined in the Agile framework. It can be people managers, delivery directors, etc. Typically this is a grey area that creates lots of confusion and finger-pointing.
Step #3: agree on metrics for each step to identify bottlenecks and delays or any waste you want to eliminate. You can explore measuring Cycle time and Lead time for the start.
Try to break dependencies instead of managing them
At first, we focused on creating a perfect process of managing dependencies. We decided what ceremonies to put in place, made a fancy board of dependencies, and tracked dozens of metrics to identify bottlenecks. It felt that dependencies were under control for some time. Unfortunately, as soon as the company started growing and as we added more teams, identifying and handling dependencies became more complex and turned into a never-ending disaster. At some point, dependencies became so overwhelming that managing them was no longer an option.
After multiple discussions, we concluded that we needed to look for ways to break dependencies instead of managing them. Otherwise, increasing our speed to market would become impossible. I am not going to lie - it was a long and painful process. We had to work with architects for many hours to see how they could decouple the solutions so that teams could own products independently. Also, we conducted numerous meetings on restructuring teams to break the silos and create truly cross-functional groups. In the end, it paid off very well. Even though we never managed to get to zero dependencies, reducing them by half was still a big win. As a result, we saw a significant reduction of communication overhead and many improvements in teams' velocity and overall performance.
Scarce or zero involvement of Scrum Masters in Agile transformation
Unfortunately, I've seen this antipattern many times, and the companies where I worked were not an exception. Scrum Master's role was mainly perceived as someone who operated on a team level only. However, if we look at the Scrum guide, one of the responsibilities of a Scrum Master is to lead and coach an organization in its Scrum adoption, which is a part of Agile transformation. Of course, most Scrum Masters won't have enough knowledge about how the company operates on an enterprise level. Still, they should understand the fundamentals of Agile principles and values, which makes them valuable contributors in many discussions about handling change. Also, Scrum Masters, compared to leadership, have more insight into how things operate on a lower level and can provide valuable feedback on how suggested solutions can impact the teams.
If you want your Agile transformation to be successful, make sure your Scrum Masters are working closely with Agile coaches or other transformation leaders. That way, you will create constant feedback loop on how teams are doing and make course corrections on what has to improve.
No assessments
I remember once we were discussing changes made towards becoming Agile. It started to feel that not everyone was on the same page on what "the company being Agile" meant. At that moment, we realized that it could become a big problem. We aimed for different results at the end, which contradicted each other. Some people believed our goal was to become more innovative, while others wanted to see more predictability that waterfall could not provide. Also, there was a big disconnect on whether only the development teams should work in the Agile framework or it should cover all the functions of the company. After many lengthy discussions, we finally came up with assessments that represented the agreed-upon success criteria of Agile transforming ation. It was also an excellent mechanism to have regular checkpoints on the progress made towards our goals.
There are already many available assessments online which you can download and adjust based on your company's needs. I would recommend looking into Agile teams' self-assessments, which helps teams see where they are and take the next steps to increase agility. Also, invest in business agility and portfolio management assessments as those areas significantly impact Agile teams' performance and delivery process. A continuous learning culture is something you want to measure as well. Last but not least is psychological safety, as creating a safe and open environment is very important for improving teams' performance overall.
Comments
Post a Comment