In previous works (Part 1, Part 2, Part 3) we started from the assumption that you decide to implement Agility and you want to do it well -- that you don't want to do it just “naoko” or you don't want to “take only what makes sense to us” (in other words: not change much). Therefore, in our articles, we have described all sorts of indicators that will help you stay on that path of “doing well” and not distort your Agility rollout. Whether because of ignorance, succumbing to pressures that it's complex, unsolvable, or simply out of laziness.
But at some point, there comes a time when you no longer talk about Agility in an organization on a first-come, first-hand basis. Either the value of this approach is already clear to everyone and there is no need to question it, or everyone has simply got used to it. And or they all exhausted themselves through a long process of reorganization, transformation. The reasons may be different.
Challenges remain
The dynamics of the market have changed — the combination of covid, the war in Ukraine, the rise in energy prices, inflation, the massive intrusion of the topic of AI, all together caused and causes unpredictability of market developments. But then there are the good old internal factors - having several (tens, hundreds, thousands) of people in one place always means enough challenges for the company to be able to adequately employ itself.
From our point of view, the shift from the introduction of Agility for Agility itself towards specific challenges is the right development. Because it is a journey, not a destination. Therefore, the moment is right to move away from the Agility indications (see previous articles) towards measuring how much we have managed or succeeded in eliminating the original challenges that caused us to start thinking about Agility in the first place.
Examples of such challenges can be, for example, the following:
1. We are not flexible enough in responding to the changing needs of the market.
2. We need to constantly think about the value for the client and get that into the whole process and people.
3. We are too bureaucratic, we have heaps of inefficiencies, starting with a lot of inefficient meetings.
4. Our culture kills innovation and change, we are afraid to do something revolutionary that would potentially not go well.
5. We need to cut costs dramatically to maintain cashflow.
6th. Ownership of the product/service not only by the individual (Product Owner), but also by the team, does not work.
7. Our performance is based on several (senior) people who work at 200% and are indispensable to the organization, are involved in many activities and at the same time they are a bottleneck.
This list is neither complete nor universally valid. These are challenges that we very often identify with our clients. You can write such a list of TOP challenges of your company yourself and look for metrics for them.
Indicators as we stand
As soon as we face a challenge, we tend to respond immediately. Which doesn't tell us anything about whether or how well we can handle the challenge. We are only subject to the illusion that “we are doing something for the solution”, and this fills us with peace of mind.
So, to address the challenges mentioned above, let's list a few common ways to track the shift:
It's a challenge
What to watch
1. We are not flexible enough in responding to the changing needs of the market.
Speed of delivery of changes to the market (Time to market, Lead time, time to solve customer request).
2. We need to constantly think about the value for the client and get that into the whole process.
- Customer/Product Surveys.
- Evaluation of the application in the store.
- Increase in new customers, profit.
3. We are too bureaucratic, we have heaps of inefficiencies, starting with a lot of inefficient meetings.
- Employee Surveys.
- Evaluation of the effectiveness of meetings.
4. Our culture kills innovation and change, we are afraid to do something revolutionary that would potentially not go well.
- The number of shared lessons from “fuck-ups”.
- Number of finished/closed initiatives linked to ambitious OKR.
5. We need to cut costs dramatically to maintain cashflow.
Cost-effectiveness of the entire process.
6th. Integration of the product/service.
- Self-check of target behavior (see previous article).
- Proactive solution of technical debt, design and product.
7. Overloading key people.
% of time spent mentoring colleagues (mainly juniors) vs.% of backlog clearance work for senior people.
While it is true that for each metric, the trend and the time to reach a limit that we know has a major impact on us (survival, development...) is important.
If the prompts from the list in the left column of the table above are relevant to you, and at the same time you do not measure their shift in any way, we recommend that you take inspiration from the examples of indicators in the right part of the table and start measuring them. In itself, this will bring you very surprising findings (“Our app is the slowest on the market”, or “If this person leaves, we can close it. No one here has his knowledge”). Secondly, you will then make qualified decisions about how to solve these challenges and whether you will succeed.
The solution
One of our clients recently aptly remarked, “If I were to tackle each challenge individually, I would probably do without Agility. But I have to solve several challenges at once and that means for me that I can no longer do without Agility. Or I would reinvent the wheel.”
An example is the challenge 2. We need to constantly think about the value for the client and get it into the whole process.
If we only address this point, we can probably find other techniques and ways — from product discovery to mass massaging with trainings, how we need to be customer-oriented.
But when we combine it with the point 1. We are not flexible enough in responding to changing market needsSomething like Agility can hardly be avoided. After all, judge for yourself:
To solve this challenge, a good first step is to look at your process from start to finish and identify what and why is extending your delivery time and response to necessary changes. A typical reason tends to be constant mistakes and misunderstandings between people in different parts of the process. Errors that are found at a later stage of development, which is the most difficult to detect and eliminate, often have a cause in analysis that takes quite a long time and is not “perfect” anyway. Another example of typical delays is when development and testing do not communicate with each other or communicate only through Jira because they are in the home office. Then everyone tosses the mistake around like a hot potato or just nothing happens.
One solution is to place people from Business (Demand), IT and Ops in person. In our experience, it may not be 5 days a week, but 3 are critically necessary. The second step is to break large complex assignments into small deliveries, in which you do not need a 100% comprehensive analysis, but constant interaction between analysts, contractors, IT, etc. Being together means they are able to find the most effective solution. When the person who implements the task also has the context and has someone with him who constantly updates the context, we prevent that poor quality and unnecessary prolongation in the later stages of the process. Together, they deliver valuable pieces much faster, and as a result, feedback from clients comes faster if that's really what gives them value.
Let's look at the challenge 6th. Product placement together with the challenge 7. Overloading key people. These create a vicious circle in almost every organization where we have been. A group of “superheroes” participate in all discussions because they have a “complex matrix” in their head that no one else in the organization has. Therefore, no one else dares to make a decision without these “superheroes” and at the same time, their overload prevents them from dedicating themselves to carrying this context to other people so that they are more detached and can make decisions for themselves. So newcomers leave after a while, or they are unoccupied, because no one works with them. There is no one to do the job. So are “superheroes” even more of an overload. Vicious circle.
A lot of people in the organization are looking at their tasks (“I'm hired as a developer, give me a clear assignment and that's it”). But that's not enough. “We have been running on only one node for two weeks, i.e. without any backup in case of outage. Is anyone doing anything about it? What are we going to do when a problem arises?” Sounds at a typical meeting. All those present look at each other in confusion, and the answer is silence. Everyone feels that they have been fulfilled. The rest is the responsibility of the Project Manager, Delivery Manager, just anyone who is paid as a manager.
Organizations where a couple of overburdened individuals are not waiting for a decision, operate on a different principle. The main role of seniors, managers and leaders in such an organization is to create the conditions and competencies in other people in the organization so that they are able to make such decisions on their own. Which starts from setting goals and expectations from these key people -- do I wait and reward that they put out another fire? Then probably nothing will change... If I want to see a change, the goals and expectations must be the metric mentioned above, how much% of the time is spent on mentoring in question and how much “extinguishing”.
It is not a problem to stop all one stream or part of the supply and invest time in development, so that later we can benefit from this investment by delivering more relevant value.
At the same time, the entire team is responsible for the quality of delivery and its operation. If something doesn't work or alerts detect a problem, they need to take care of it. Even at night. The motivation for quality and responsibility is much greater. At the same time, I have a clear criterion of what means that I did my job well.
Surprisingly, we have arrived at self-organized teams and DevOps principles.
Conclusion
Thus, agility is not a goal, but a solution to certain challenges in the organization. When you name your TOP challenges, define criteria/identifiers, and honestly look for solutions that meet them, you will come to practices similar to the authors of many Agile methods more than twenty years ago.
If you've been through Agile Transformation, you're measuring your top challenges, and you feel like Agility isn't helping you, it's often due to a misimplementation of key principles. In this case, it makes sense to look again at the Agility metrics that we have described in previous articles. And after a while, get back to measuring those challenges.
This approach will give you the facts. When you start measuring, you can make qualified decisions. When you start to deal with challenges comprehensively, you will find that Agility allows you to solve these points together, while other approaches are more likely to deal with individual challenges in isolation.
We wish you successful measurement and coping with challenges, exactly in the spirit of: What I measure, I control. Share with us what challenges you are tackling and coping with.