An Agile Team is a cross-functional group of typically ten or fewer individuals with all the skills necessary to define, build, test, and deliver value. This is the second installment in the series on why agility fails or in general why so few results are seen in organizations.If you want to read the first one you can do so here.
The factors are varied, from technical excellence, certifications, to leadership. We will go through the factors that experience tells us are the most relevant and have the greatest impact on the agility of organizations and the very mediocre results that are obtained.
Being agile requires an environment that promotes it, however, in many organizations what we see is a facade of agility. Why do we say a facade of agility, because the fundamental changes that the organization needs are not made. The “leaders” want the organization to be agile as long as it does not mean any change for them. Because of course, leadership is always right, it should never improve or change.
Let’s explore a second factor affecting agility in organizations: agility is much more than Scrum teams.
Agility structure
Organizations with large pyramid schemes and a strong hierarchy do not achieve agility, because their leaders are not willing to change and give up power. A typical organization that wants to improve and streamline the way they work always says they want to be like a startup or they see startups or fintech as a threat, but they don’t visualize the big differences between a small company and one with a large operational structure.
Now, what is the main disadvantage with the hierarchy and its pyramidal structure? Well from the agility point of view we can find several aspects that result in slowness, less flexibility and less agility.
A first aspect is the speed of decision making. When decisions must be made, consulted or approved by a higher level or levels we have a significant delay in making that decision, no matter what that decision is. The problem intensifies if that next level, in turn, has to go to a higher level and this is repeated several times. Each one of those decisions that goes up and down levels of review or approval means weeks or months.
Emails come and go, sessions come and go. More information and additional details are requested. In the end, this back and forth happens because those who have the detailed information are the levels of direct customer contact and those who do the work, while the “higher” levels try to understand what is going on to try to make the best decision possible.
Also, depending on the decision, someone else always has to approve it, because of course, the most capable people are the ones who can make those decisions. In the end, the problem comes down to an issue of trust and empowerment. This is another aspect that hinders agility: he believes that people are not capable of making decisions.
Of course, this concept comes from the industrial era where operators only performed mechanical tasks, but in today’s world, where knowledge is everything and those “operators” are now engineers and highly trained and specialized people, it makes no sense to continue treating them as simple operators or programmers. That is why hierarchical structures make less and less sense or at least are likely to be very flat, with only 1 or 2 levels.
Organizations must learn to trust people and their knowledge, because that is what they were hired for. Leaders must begin to see themselves as facilitators and not decision makers, working side by side with people and giving them everything they need to carry out the tasks that will result in the achievement of the organization’s objectives.
Business model and strategy
One aspect that is usually overlooked when talking about agility is a shared understanding of the organization’s raison d’être and a clear understanding of how business works and in general how the organization creates, delivers and captures value.
Without the clear direction of a strategy and business model it is very difficult for an organization to be agile. Because we can have many teams running Scrum, but if we don’t know what we really want to achieve and what is really valuable to the organization, the teams’ efforts will simply be wasted. Being fast is not the priority, because if we go in the opposite direction we will be going backwards.
The strategy and business model must be clear to everyone in the organization. This will allow them to act accordingly, with responsibility and with clarity of the objectives to be achieved. In other words, it is not enough to have a strategy if the people within the organization do not know and understand it.
Without these shared objectives, each team or area could be doing things in opposite directions, nullifying any progress. They also won’t be able to make the best decisions and every step will be slow and painful. Transparency is key when we talk about strategy and business model and is also a fundamental enabler for teams and decentralized decision making.
Systems and technology
Normally the organization focuses first on building equipment to support its systems: core systems, digital channels and other satellite systems. However, many of these systems have been under construction or maintenance for many years, even before concepts such as technical debt were introduced in the organization.
This means that these systems are large, complex, difficult to maintain and have a significant technical debt (which increased over the years). Now, how could a team, even with great maturity and experience deliver value sooner, with a system already in obsolescence? It would probably have to focus on paying off a significant portion of the technical debt involved in maintaining a system like the one we described.
That also means that the team’s ability to deliver new value will be seriously affected. It may even, depending on the case, make value delivery impossible. Now, what could we do to solve this problem? Instead of trying to shorten Sprints, build more teams, hire more people, certify more people, etc. what we should do is to attack the root problem. And this root problem is a technical problem, which must be solved through engineering practices and systems architecture. It cannot be solved with Scrum alone or even less with some scaling method.
Sometimes the medicine is hard to take, it can mean redoing systems and stopping the delivery of immediate value to the user in order to take two steps back and start again. No organization likes this. Business doesn’t want to stop and competition is always a risk. But if we really want to be agile, team building is not enough, we must be clear that we have engineering problems that need to be solved. And that until those problems are solved, we are not going to achieve the agility promises on offer.
Some agility drivers will say: let’s pay off this debt and solve the problem of these systems bit by bit, Sprint by Sprint. Let’s imagine that the debt on a system is equivalent to a million dollars. Let’s also imagine that, somehow, that debt is not going to grow anymore. Now let’s imagine that at each Sprint we make a small debt payment of one hundred dollars, representing 20% of the equipment capacity. What’s more, let’s imagine that we can pay off a thousand dollars of debt in each Sprint. How long will it take the team to pay off that debt? You already know the answer and you also know that in this case the promises of agility will be seriously compromised.
The recommendation: don’t let systems become obsolete, control the technical debt from the initial construction and make sure that everyone is committed to technical excellence. If you are already sick, take the medicine, even if you don’t like it.
The agility processes
Processes are obviously one of the aspects that most affect or drive agility. Without a thorough review of the organization’s processes, little or no agility can be achieved. In terms of processes, we refer to how to have short feedback and learning cycles. How processes must be value-delivery oriented and must be transparent. In other words, we must know and understand what is happening in the processes in order to improve them. Processes are always subject to continuous improvement and for this, information about what is happening in each process is fundamental.
We have seen that in organizations, processes are not designed with the delivery of value and the customer in mind. That is, they are considered a tool for the organization’s operations, compliance, standardization, etc., but rarely is thought about how the process affects the delivery of value to the customer. The objective of the processes is lost and they become an end in themselves.
When processes are very large, complex and rigid, what happens is that people follow them to the letter to avoid being blamed for a mistake (blame culture). This also means that people do not contribute improvements to the processes, because they are used to execute them in a certain way and that is why they are considered good collaborators. Collaborators who are critical of the processes are rather pointed out as rebels and their ideas are discarded almost immediately.
For agility to permeate the entire organization, processes must always be redesigned with the customer and the business in mind. They should be as simple as possible and always open to improvement. If people can improve the processes they work with all the time, we will be closer to being an agile organization.
The people
This aspect is a little more visible when talking about agility. However, we have seen that some people-related characteristics are not considered and therefore affect the agility of the organization. Let’s look at some of these people-related characteristics that we need to have an agile organization:
- Empowered people: teams can make their own decisions and are accountable for results
- Shared leadership: leadership becomes more than a job title. Servant leadership is something that people can practice on a daily basis
- Community of people: Teams form communities and these in turn provide support and manage information transparently
- Flexible roles: people have the ability and willingness to take on different roles as the situation warrants. Specialization does not become an impediment, but a transition step towards a greater contribution of value, looking for each person to develop more and better skills (T-shaped)
One of the great challenges that organizations experience with people is to determine which of them are willing to close their gaps and become a valuable team player or, on the contrary, which people should look for another option within the same organization or outside of it. There are people who want to grow, learn new things and contribute to the shared objectives.
These people can be supported to develop the new skills that the organization requires. There are also people who are very happy doing a low-profile, mechanical job with little or no responsibility. These people may not be able to adapt to the new requirements of the organization on their way to agility.
In conclusion, agility cannot be seen only as the creation of teams, whether they use Scrum or not. The agility of an organization goes far beyond that. If an organization is not willing to face all the challenges and changes that achieving agility requires, they are not going to get the results they are looking for. We must say that some agilists bear part of the responsibility for this as well, because they know and sell only a fraction of what true agility is.
In short, this is the main reason why agile and Scrum deliver so few results in most organizations. How close is your organization to agile? Schedule a consultancy with us, together we can build the agile dream team.