Have you ever wondered, in the context of Scrum, if it’s possible to keep agility in your software product development while following rigid processes? Have you ever assumed that as Scrum is agile by nature, there’s no point in questioning its agility? Admit it, at least once you must have thought to yourself, is Scrum even agile?
But first, how can we prove Scrum’s agility?
Scrum’s agility is about being able to react quickly to product requirements, sprint ranges, and their adaptation to the market, product situation, customer requirements, and feedback. With Scrum, software product development teams are enhanced in delivering business values in the shortest time by rapidly and repeatedly testing and inspecting software that is currently working.
In terms of product development, this framework focuses on responsibility, teamwork, and iterative progress towards well-defined goals. In its assumptions, Scrum is 100% agile as it usually deals with the fact that requirements are likely to change or are mostly unknown at the initial phase of the project. If you want to be responsive and adaptive to change then you have no choice but to embrace the agile approach.
What stands out against the agility of Scrum processes?
Scrum, as an agile framework, has a well-established and concise set of rules, roles, artifacts, and procedures. This fact alone seems to be a contradiction to Agile’s “spirit”.
If you read through the Scrum Guide, it defines specifically what Scrum is and it exists only in its entirety. Try to leave anything out and you’re not doing Scrum anymore. And yet, any kind of technique or method that tells you how to work is, by definition, not agile.
Scrum processes are rigid, rock-solid ways from which you can safely build your project. But for the same reason, they cannot be considered agile. If the team decides to change something in the processes or to skip some parts entirely, this could be the first step to putting the project on the wrong track.
The rule is simple: if you intend to work in Scrum procedures, you must obey and follow them exactly as stated. Even missing just one of its artefacts and roles will cause Scrum not to function anymore. It becomes aberrant and slowly poisons the project by gradually increasing the number of areas that do not follow the correct procedures.
The agile approach, on the contrary, means you have the freedom to choose the right tool or artefact to enhance your actual process. When it comes to the Agile process, leadership plays a vital role. On the other hand, Scrum successfully fosters a self-organizing, cross-functional team.
At the end of the day, the results matter more than processes.
Scrum is about delivering value and not about getting work done easier. You could go away and produce twice the garbage in half the time but that’ll get you nowhere. What you really want to be doing is product development that delivers good, quality work that’s valuable to people.
If your final product isn’t clearly defined and there are a lot of unknowns that might evolve over time, Agile deals with these changes effectively. It enables an easy implementation of new requirements or features throughout the process. While the intention of Scrum processes is nice, everyone knows real life isn’t so kind.
If you’re agile, your product development should be ready for changes or new tasks. But are we always able to cope with this extra workload? For example, it may turn out that there is a new task that needs to be done quickly for the stakeholder but your sprint is not flexible and it just crumbles after the introduction of this extra task. Even though you planned, estimated the story points and set the course of events, during product development it still turns out that you are not delivering on time. So you start shuffling tasks around or making new estimations but time is running out and there is no space for proper analysis. Your smooth, well-oiled machine starts to jam.
Once again, is it possible to keep agility in your software product development while following a rigid process? If you have a hard-line process like Scrum, then you are not able to respond in an agile way to product changes. And yet the ability to implement such changes lies at the core of Agile. Scrum processes that should have a positive impact on the final product actually, in the product development process, turn out to be an obstacle.
Culture eats processes for breakfast and rules for lunch.
When you’re agile you’ve got to stay flexible and be able to change things on the fly as you learn. It’s not an accident that the Agile Manifesto has only one practice in it: continuous learning and improvement.
This methodology was intended to gradually remove unnecessary components of the development process and provide a lightweight framework for project management. This leverages the creativeness and technical knowledge of the developers as a consequence. Scrum, on the other hand, is all about doing things exactly as prescribed by the framework.
There is one more important aspect and a consequence of working in Scrum: If you want to develop the team’s autonomy, and if you want your developers to be adaptable and have the ability to think independently, you cannot do it with only Scrum processes. There is simply no space for progress in it. Even the regular retrospectives are not enough as they are not a tool for improving processes because they are concerned with reviewing the deliverables and the current sprint activities that have been done.
To enhance the team’s progress you must reach beyond the given processes. Actually, there is no space in Scrum for acquiring domain knowledge, in-depth analysis of the functionalities currently being developed, user analysis, or even for the reviewing requirements provided by the stakeholder.
There is some correlation between the team’s maturity and its ability to deliver products in an agile way. For some teams, abandoning its procedures may mean more autonomy, greater ownership and more overall self-development, while for others only greater… chaos. For some teams, breaking free from procedures means greater progress towards agility, but for others it is the exact opposite! The decisive factor here might be the level of experience. A mature team knows that specific frames and patterns should be kept but they can freely, in an agile way, choose the right ones for the project.
Agility won’t happen in an immature team.
The maturity of a development team is quite a relative term and it’s hard to set the specific criteria of qualities and behaviors that make a team highly mature in terms of agile. However, it’s possible to recognize some “symptoms” of a team’s maturity in the context of being agile.
The maturity of a team should determine which processes you follow (or if you’re doing it at all). In Scrum, for example, daily standups might be helpful to keep tasks flowing smoothly as well as the rhythm of the development cycle. However, they aren’t necessary for more mature teams.
For “younger” teams that are just starting out with Agile, having strong processes, such as those given in Scrum, is important. But this is only the first step of going agile. As the team matures, it should strive to get the job done with fewer processes and patterns which will become brittle as the years go on.
A well-run agile team can detect and respond effectively to any change that occurs. But when you follow Scrum blindly there is a risk that you’ll “stick to the plan” instead of learning the domain or you won’t be ready to respond to changes in the environment that might influence the business.
For “younger” teams with no high-level seniority and a lack of experience, the risk lies in over-trusting and over-believing in the processes. There is a high risk of falling into a false sense of security. What can go wrong as we follow procedures?
Some teams are convinced that they remain fully agile because they keep processes and let the framework think for them. Paradoxically, this way they are less agile than they used to be before the agile methodology was introduced to the organization.
Over time, tools and procedures will become so ingrained in how you do things that they will become second nature. Scrum elements will be “replaced” by a certain mentality, an agile mindset. This change in the team’s approach might be almost imperceptible but yet it is still significant. It’s about focusing on the wider perspective rather than on the short period of the work you’re currently engaged with.
Summary:
Although Scrum is perceived as an agile framework, it doesn’t adhere to all the principles that make agile unique.
That being said, it’s definitely not a bad place to start for teams and companies that want to embrace the agile way of delivering products. It’s just important to remember that Scrum is not a one-size-fits-all solution.
Eliminate aspects of your processes that get in the way of real progress. Use Scrum to teach your team maturity and create a selection of artifacts that will eventually create a framework that works for you.
The important thing to know about agile software development is that it is not something that can be applied overnight. It is a process in which teams develop the ability to bounce ideas off each other, testing the viability of new approaches before committing them to development.
Adherence to Scrum principles doesn’t mean giving up on agility. Failure to understand its principles – definitely does.
“Scrum is simple. Try it as is and determine if its philosophy, theory, and structure help to achieve goals and create value. The Scrum framework is purposefully incomplete, only defining the parts required to implement Scrum theory.”
