Agile - Still Relevant in 2024

Changes to this text

• 2025.01.19: Modified the text a lot and removed parts not relevant to main point

During the first half of 2020’s it has been common to see a lot of critique towards agile, and it can be easy to overlook how fundamental agile principles remain for surviving fast-paced, complex software projects.

Agile is a mindset to survive in a complex environment

I understand the frustration: agile frameworks tend to be marketed and branded products these days, and they are often applied in a superficial way, by people who don’t understand the consequences nor carry out the responsibility of actually fulfilling the needs of the customers.

The development teams may be allowed to play “agile” in those boundaries, as long as they do all the reporting, and deliever in time and in buget the fixed-priced project the separate sales team has sold (and received a bonus for that brilliant work).

I would like to remind, that agile (agile manifesto) is fundamentally quite a simple iterative and adaptive mindset to help you work in a complex environment. Having worked through both agile and waterfall-like approaches, I’ve seen how companies tend to crave for control - in the expense of agility.

Different frameworks and models can be designed to implement agile principles and values, but they are not synonymous to “agile”.

Face the friction, early

Trivialisation is a belief that complex systems (see Cynefin) can be modeled and managed the same way ordered systems can thus resorting to using existing practices better suited to ordered systems (from Nachbauer, 2021).

As one of my more experienced colleagues said, when people try to act in a non-agile way, they want the process to feel easy and safe. Doing intensive planning, getting the predicted deadline dates and starting the work feels safe, and makes “common sense”. Unfortunately that safe feeling transitions to the pain towards the end, when the plan meets the reality and the illusion of control breaks.

It is easier to apply the waterfall-type of thinking that works in a static environment, and refuse to face the real complexity of reality. Some organisations do this by buying the software from subcontractors by dictating the contracts (if they have the economical power), or by demanding impossible work performance from their employees (quite often a pathological organisation by Westrum culture classification).

It doesn’t mean these people are mean or want to take advantage of others. It’s quite a natural tendency to try and have some order in your environment, and that’s what waterfall-like processes and contracts bring: artificial peace of mind and clarity right now.

Agile mindset indicates you should embrace the unknown and face the pain early on, during the process. That way you start learning, and the work actually gets easier and rewarding towards the end.

Agile starts by admitting the world is unpredictably complex

Agile thinking begins from admitting that the environment is quite complex. Complexity means we can never fully plan our work beforehand, because even the best plans will be made obsolete by changes along the way.

Going forward in small steps that are designed to test your assumptions and maximize learning is more successful than trying to do the Big Design Up Front. This is internalizing conventions that answer to the needs of an unpredictable and complex environment (see Cynefin for explanation of complex, compicated and simple domains).

A better term for agile might be adaptive.

Complex environment can feel out of control, if you are used to thinking that you “invest x amount of money and time and get y”. That’s often the premise in a public tender: We want to get , tell us how much money and time you would need to make it happen, and we’ll pick the cheapest one.

That totally misses the point of learning, and will fail.

Use the agile manifesto to guide your thinking

When you are making decisions on the way of working, take a look at the agile manifesto:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more.

…and consider if the decision you are making is taking you towards left or right, and if it’s justified and is following the principles.

These are no binary choices: Individuals and interactions over processes and tools does not mean, we have zero processes and tools. Responding to change over following a plan does not mean we have zero plans, or that we don’t do any design.

Processes tend to outlive their creators, so be wary of how much process you add (especially if you start to consider company-wide policies). You should strive to refuse additions that feel easy because they are based on a non-complex, predictable worldview.

One practical example is quality control:

A bug is found in the production, and the first instinct is to add processes to reduce the probability of another bug ever getting in to production. It’s more useful to admit it’s impossible to have zero bugs, and instead ensure that a) they can’t destroy the world, and b) they can be detected and fixed fast (see DORA).

Agile never looks the same

The best process is context dependant. Therefore it’s impossible to say what what exactly is the optimal process you should always use. However we can say your process should be based on the correct understanding of how the world behaves.

The team should have all the needed knowledge, skills, experience, and most important, the mandate to figure the process out. If you say “we are a Scrum house”, it means your teams are not agile: they don’t have the freedom to select and come up with their own process to meet the demands of the task at hand.

This doesn’t mean it is a wild west: of course the team full of competent professionals takes into account the local software development culture, and proactively seeks to understand what kind of interactions the team should have with the rest of the organisation, other teams and stakeholders.

Individuals and interactions part is hard

One of the hardest things for the team to do is to bring the peace of mind for those stakeholders that are responsible for the success (money) and / or don’t understand how software is built successfully.

I’m a big fan of showing, not telling: show them every week what has been accomplished and what the way forward looks like.

Have discussions using the running software, whiteboard or mockups as a shared entity, not Jira. No jira traffic light can tell you you are doing OK.

Agile empowers autonomous cross-functional teams

Context dependency and complexity are some of the reasons why experience is so important in software development.

When we are doing complicated things, pure skill is enough. In complexity, you also need the experience to detect patterns and evaluate what could be the best way forward when you can’t know it.

Individuals more often than not don’t have broad and deep enough skills and experience: you need a team. As diverse (experience, background, skills) a team as possible.

A team must be autonomous so it can adapt to the changes in its environment fast. It must be cross-functional to own the experience all the way to the end users, to optimize the feedback cycle.

If a team like that is motivated and willing to have a shared responsibility over the outcome (not output), you can throw them any problem in any environment, and they will come up with a process needed to solve it.

Conclusion

Ultimately, agile is about empowered people, continuous learning, and rapid adaptation. Whether you follow Scrum, Kanban, XP, or another framework, remember to revisit the underlying principles. If your process feels stiff, question whether it’s truly agile, or just agile in name. Give your teams autonomy, embrace experimentation, and you’ll find that agility is alive and well in the face of complexity.

If you are in leadership or buying, make a thought experiment in which you consider that all of your assumptions about the problem and solution are false. What would be the fastest way to find that out and learn?