Introduction
Agile and its Ways of Working has grown into a popular approach in software development in the last few years, no less escalated by the impact of COVID-19.
And for most business, agile as an iterative and incremental methodology that emphasises short cycles of feedback, automated testing, collaboration, and continuous improvement over a long-term plan, is extremely attractive, especially in the current VUCAH (Volatile, Uncertain, Complex, Ambiguous & Hyperconnected) environment.
It’s no surprise then that Agile has been adopted by many businesses and industries to improve their software development process, business & strategy process to reduce risk, increase productivity and ultimately be more successful in creating and releasing solutions for their customers.
Its flexibility and focus on people rather than processes and tools have even made it a favourable adoption by non-IT departments.
With many benefits, agile is certainly deserving of its status as an efficient way to optimise and improve the work environment and team dynamics.
But like all things, it can create challenges and impediments, especially when it is misunderstood, wrongly applied or worse, implemented dogmatically.
Now, in some cases, dogmatism can be good. But historically, people are not capable of balancing dogmatism with reality.
There are areas where dogmatism or rather, commitment to certain processes is necessary and somewhat immutable such as the running of a sprint, and conducting a review and a retro. These are core and instrumental to the entire process. When we say dogmatism is disruptive, we mean being inflexible to the point where no consideration is made as to the wants or ability of the organisation to transform. Instead, the transformation coach is rigid in implementing processes without first understanding how to fit things together.
Dogmatism by its very definition promotes inflexibility which can be anathema to agile. While more common in a waterfall organisation, even then, dogmatism can be disruptive. Dogmatism breeds rigidity and can be off-putting to newcomers as well as veterans.
There are stories about rigid leaders forcing teams to go down a misguided path, only for that to result in a product misaligned with the market while potentially wasting hours of hard work and investment.
Dogmatism outside of agile can already be damaging. In a methodology that puts people over processes, it risks affecting not just the success of an agile transformation and adoption, but also team dynamics and culture.
What is agile dogmatism?
Agile as an adaptive and flexible alternative to the traditional, waterfall way of working is attractive. Yet, it is ironic that some practioners adhere to the agile manifesto like doctrine to follow to the letter while forgetting it is also about learning and adapting.
This is the idea that you can't deviate from the agile manifesto, from agile process, or agile values—meaning that if something isn't working for your organisation and its needs, you must keep doing it even if it doesn't work well.
The issue with this approach is that organisations don't change overnight. Once they've been set up in an effective way (whether they're following scrum religiously or not), they often get stuck because there's no incentive to change the way they operate, until problems arise again. It's not necessarily a problem, but rather the understanding of why they need to change is often lost on the decision makers who may not have visibility on every nuance in the organisation.
And when those problems inevitably start cropping up without any noticeable improvement made - (because people aren't trying anything new), the prevailing assumption is that something's gone wrong with their project management process.
On top of that, they may erroneously assert that agile doesn’t work for them, failing to realise that it was implemented inefficiently, because the approach was to treat the manifesto like text too sacred to interpret according to differing context.
But it is understandable. People unfamiliar with agile, especially organisations that adopt it without the help of a trained coach or consultant, tend to approach it from a dogmatic perspective as they lack key insight, expertise and context into the process, especially the nuances that only a trained coach can bring.
While agile requires a full and proper implementation of its process, it is implemented once the consultant understands how the organisation has worked in the past to better fit the pieces together, using their expert knowledge of agile (and its various methods) to create a way of working that benefits the organisation.
It should be like snapping different coloured Lego bricks together, where the pieces are visually distinct, but they fit together nonetheless to create something new, exciting and fundamentally sound.
In essence, agile dogmatism is an anti-pattern to be avoided. Unfortunately, as more organisations attempt agile transformation, dogmatism will grow if left unchecked.
Where is agile dogmatism seen?
Most common and obviously, it’s seen within the agile community.
In coaching, it’s common for a coach to constantly point out instances where the client isn’t using a particular methodology or following a specific set of practices. It’s a way to differentiate the traditional form of working from agile.
But there's a big difference between following the values and principles of agile software development—such as focusing on delivering value to customers, prioritizing simplicity, and valuing individuals over process—and trying to force a specific approach onto every project under the sun.
The latter is what can be referred to as agile dogmatism.
Agile dogmatists can be found anywhere that software is produced: from teams within an organization to conferences and meetups outside of work hours (or even during work hours).
It’s a natural occurrence, especially among people more prone to becoming evangelists for something. It works for them, and they are driven by the passion to foster it on someone else. Unfortunately, this is generally a result of a lack of holistic experience and knowledge.
This kind of behaviour becomes especially problematic when mixed with the typical dynamics of workplace environments where teams have little choice about which working style they adopt for their projects.
It's important to remember that being Agile is a set of values and principles, not a methodology. It doesn't prescribe any specific practices or tools; instead, it provides guidance for how to adapt your approach based on the situation at hand.
What is the effect of agile dogmatism on the workplace and team?
We touched on a little in the above section but to codify the effects agile dogmatism can have on the workplace and team, it can result with people that:
- Are unhappy
- Are not learning
- Are not growing
- Are not improving
- Are not doing their best work
When agile becomes a rigid structure forced on people, it creates a lot of unrest and discomfort, especially with people who are more familiar with it and understand it to be something else. Continuing in this way, you risk your staff no longer taking risks because it’s not worth it to do so.
As a result, staff creativity and experimentation are at a decline as they are just doing their jobs to collect a paycheck rather than feel motivated to go above and beyond. Agile dogmatism may also end up ignoring the organisation's uniqueness which would have a negative impact on everything.
Over time, as these issues compound, staff may start dreading work - a slippery slope difficult to climb out of.
How do you overcome dogmatism in a team or workplace?
At the risk of sounding like a broken drum, the best way to avoid dogmatism is to understand the purpose and meaning of agile. There is a reason why it’s so often emphasized.
Agile is about people over processes and tools. It is a set of values and principles that serve as a guide. It is not an application to be implemented totally in a do or die manner.
Click: How why innovation! can help you
To avoid the pitfalls of dogmatism:
- Be open to new ideas
- Encourage people to ask questions
- Don't be afraid to admit that you're wrong, or that your idea isn't the best. If it's not working out, change it
- Be inclusive—don't exclude people just because they haven't been doing agile for as long as others in the team. Diversity in thought is good, and you can benefit from an outsider/newcomer’s perspective. Don’t attempt to do everything yourself. Get others to help
- Practice active listening
Don't be afraid to fail. It's okay! Learn from your mistakes and move on. Don't let it get you down—everyone makes mistakes, and that’s just part of the learning process. Agile encourages people to learn from failure. In fact, it is a big component of the agile development process. If you follow only the structure rigidly, you end up missing the important aspects of agile which involves people and culture.
Agile dogmatism can be avoided
Early on we established that agile dogmatism can be a problem because it prevents teams from improving by actively taking agency away from them and locking them into a rigid, inflexible process. If team members are not allowed to make changes or learn new things, they will likely get stuck, and their performance will remain stagnant.
Agile dogmatism is a problem because it prevents teams from learning. If the team members are not allowed to change their behavior, they will not have an opportunity to explore new ways of working together and learning from each other's skillsets.
They may also miss out on opportunities for cross-functional collaboration with other teams in the organisation if there aren't many opportunities for interdisciplinary communication within the current structure of each team (which tends to happen when people stick primarily on one side of an issue).
When your team isn’t working with others, silos can form that would create other problems like tribalism within the organisation. And your team won’t learn from others or be aware of what’s going on outside of themselves.
It also prevents teams from adapting to new situations. Without having access to different viewpoints about how things should be done differently based upon customer feedback or market conditions outside our control (like sudden changes in regulations), we're unable to adapt quickly enough when situations change unexpectedly.
Sometimes these changes can happen overnight, which makes being able to adapt quickly an extremely vital and important skill.
Dogmatism can also negatively impact innovation. If we're not allowed to experiment with new ways of working together or collaborating across teams, then your creativity will be stifled.
This is compounded if quality feedback received, juxtaposes with the product owner’s own dogmatic agenda.
People quickly learn that there is little point or reward in making effort if that effort fails to fall within a myopic, limited viewpoint.
Conclusion
It’s important to understand that proper Agile transformation and adoption cannot be successful if it is applied and adhered to dogmatically.
It’s a philosophy and mindset. The key principles of Agile are flexibility, adaptability, and collaboration. These are not things you can be dogmatic about; they are flexible and adaptable themselves.
And these values need to be applied all the time—whether we’re talking about sprints or iterations, product roadmaps or user stories, testing practices or technical debt management strategies—because every situation is different from the next one!
Don't get too attached to your processes and tools. Always keep an open mind for adjustments that may better fit the needs at hand.
There is usually more than one solution to a problem, but if you’re dogmatic about agile, then you can’t see past it to use the other tools in your toolbox, at the detriment of everyone.
Don't fall into this easy trap. Engage the services of an experienced coach/consultant to help guide and direct your organisation toward a successful agile transformation.
Our coaches are not just knowledgeable of the many processes, but they are still practicing, and honing their skills in different companies and industries. Whether you're a big or small organisation, it won't matter. We can help you. Reach out to us here.
