In the Oxford dictionary, the word agility is defined as “the ability to move quickly and easily”. It is therefore understandable that many people associate agility with speed. Which I think is unfortunate. I much prefer the description by Sheppard and Young, two sports science academics, who proposed a new definition of agility within the sports science community as “a rapid movement of the whole body with a change in speed or direction in response to a stimulus” [1].
The term “agility” is often used to describe “changing direction of speed”. However, there is a clear difference between “agility” and “change of direction of speed”. Agility involves the ability to react in unpredictable environments. Changing direction of speed, on the other hand, is aimed solely at maintaining speed while changing the direction of travel. Maintaining speed while changing direction is usually only possible if each change in driving direction is known in advance.
Using a sports analogy as an example, in football we can say that the reaction of a defender to a sudden movement of an attacker is a movement based on agility. The defender must react based on what the attacker is doing. Contrast this with an athlete zig-zagging through a course of pre-set cones, the reactive component missing. There are no impulsive or unpredictable events. The athlete tries to maintain speed while changing direction.
Often, when organizational leaders want to adopt Agile, they do so for reasons such as “to deliver faster.” In this case, they think of agility as a way to enable a change of direction of speed like an athlete, not in terms of the agility a football defender needs when facing an attacker. This may explain why agile ways of working do not always live up to expectations, even though more and more companies are adopting them.
Sticking to the sports analogy, the athlete running through the cones tries to reach each one as quickly as possible, and then runs in the direction of the next one until the end of the course. This works as a metaphor for defining the scope of a project and prompts teams to work in short iterations where they deliver each planned feature as quickly as possible and then move on to the next. This may be fine in a predictable environment, where the plan does not have to change, where the requirements remain fixed, where the market remains the same, and where customer behavior is well understood and set in stone.
However, in many environments, change is a constant: customer expectations and behavior, market trends, competitor actions, and more. These are VUCA environments (volatile, uncertain, complex and ambiguous) where there is a need to react or, in other words, where agility is required. Frameworks such as Scrum are intended to support agility. Sprints are short planning horizons, and artifacts and events in Scrum are there to provide greater transparency and opportunities to review and adjust based on early feedback, changes in conditions, and new information. It gives the opportunity to turn and react in time. However, Scrum is unfortunately often misunderstood as a rapid delivery mechanism.
Focusing only on speed and delivery and not investing in practices that enable true agility will likely actually slow things down in the long run. When the focus is only on speed, that speed becomes harder to maintain, let alone increase, and any semblance of agility is a fantasy. Let me talk about a pattern that I see as an example time and time again.
Company A aims to build an e-commerce site where it can sell its goods. Their first piece of functionality is delivered in a one-month Sprint and consists of a static catalog page where a company can upload their products with a short description. The first delivery is received by happy and excited stakeholders who are hungry for more. The team continues to build, and the product grows.
Stakeholders are making more demands, and the team is working harder to keep up and deliver at the pace that stakeholders expect from them. The team has no time to invest in improving their practice. Manual regression testing is becoming more and more of a burden and more challenging to perform within a sprint. The codebase becomes more complex and fragile. The more bloated the product becomes, the more the team struggles to deliver at the same pace. To try to meet expectations, the team starts cutting corners. They end up transferring testing work from one sprint to another. And there is no time to verify that what is being delivered actually produces value. That’s just as well, because no analytics have been set up anyway.
Meanwhile, while the team is so busy building new features and doing manual integration and regression testing, they don’t have time to look at improvements to their original build pipeline or incorporate any automation. Putting it into production involves several hours of downtime, so it has to be done overnight and manually. To make matters worse, the market is changing. The sales team has contracted new suppliers, but this means additional website customizations are required for their products. After all, the company is committed to making the platform available in different time zones, so release delays are a big problem and need to be kept to a minimum, so they should only happen once every six months.
Progress comes to a standstill. The product is riddled with technical debt. The team has lost the ability to get early feedback and the ability to react to what their attackers are doing, i.e. changing customer needs, competitor actions, changing market conditions, etc.
The mere implementation of framework mechanics such as Scrum does not ensure agility and does not automatically lead to a more useful way of working. The Agile Manifesto includes principles such as “continuous delivery of valuable software,” “continuous attention to technical excellence,” and “at regular intervals, the team reflects on how to become more efficient.” Following these principles enables greater agility than just following the Scrum framework. One effective way to enable greater agility is to complement something like Scrum with agile engineering practices to get the expected benefits organizations are looking for with agility.
Over the years, I have encountered many Agile adoptions in companies where a lot of passion, energy, focus and budget has been invested in training and coaching people to implement certain frameworks such as Scrum. However, what I don’t come across as much are companies that spend the same amount of passion, energy, focus, and budget to implement good Agile engineering practices like pair programming, test-driven development, continuous integration, and continuous delivery. When challenged, the responses are usually something like “We don’t have time for that right now” or “Let’s just ship this next release, and we’ll do it later when we have time.” And, of course, that time usually never comes.
Now, of course, something like Scrum can be used without using any Agile engineering practices. After all, Scrum is just a framework. However, without good engineering practices and without striving for technical excellence, a Scrum team developing software will only get so far. Agile engineering practices are key to achieving agility because they enable shortening validation cycles and obtaining early feedback. For example, validation and real-time feedback on quality when pairing, or that comes with proper continuous integration.
Many agile engineering practices are considered intimidating and expensive to implement, and this will hinder delivery. However, I would argue that investing in engineering practices that help build quality or enable the automation of tasks, for example, enables sustainable development in the long run. While investing in Agile engineering practices may seem to slow things down in the short term, the goal is to maintain or actually increase speed in the future while maintaining the ability to pivot.
To me, it’s an obvious choice to invest in implementing Agile engineering practices, but surprisingly, many companies don’t. Instead, they choose to sacrifice long-term sustainability and quality for short-term speed.
Creating a common understanding of the challenges teams face and the trade-offs for short-term speed without good engineering practices versus the problems that can arise without them can help start the conversation. It’s important that everyone, including developers and team stakeholders, understand the importance of investing in good Agile engineering practices and the impact on agility if you don’t. These investments can also be considered experiments—trying or exploring a particular practice over a few iterations to see how it might help can be a way to get started and make it less intimidating.
In any case, it is questionable that an agile process without the application of fundamental agile practices can be agile at all. For sustainability, robustness, quality, customer service, fitness for purpose and true agility in software development teams, continued investment in agile engineering practices is important.
[1] JM Sheppard & WB Young (2006) A review of the agility literature: Classifications, training and testing, Journal of Sports Sciences, 24:9, 919-932, DOI: 10.1080/02640410500457109