Many times, when I start working with a team, there is at least one person who is very enthusiastic about adopting Agile. They may even devote themselves to Agile as a religion of sorts. Unfortunately, their enthusiasm often isn’t matched with enough (or any) real-world experience.
This devotion, combined with inexperience, can lead to several issues, including:
Frustrated team members
An even more frustrated management team
Low velocity
Banning of Agile as a framework due to poor initial results
Passing around lots of misinformation
Definitions:
Goal of Agile: Allows teams to adapt to changing client needs and shifts in market demands, responding to evolving product requirements while supporting a sustainable work environment.
Velocity: A metric used to gauge the amount of work a team can complete in a single iteration or Sprint. It’s an essential tool for planning and forecasting in Agile methodologies, particularly in Scrum.
Going from Suck to Awesome
Sucks – A rigid, nearly religious devotion to a process that’s sacrilegious to deviate from, combined with a weak or non-existent continuous improvement loop. This can lead to disastrous results and kill team enthusiasm, so they never try anything new or different. When team members overlook the realities of the work situation and never address how these rigid rules are preventing them from getting work done, leading to frustrated teams and management.
Sucks a little less – Understanding that Agile will change and adapt but placing tools, processes, and an overly restrictive framework over people and their goals and needs.
Awesome – Embracing the ability to change and adapt. Unlike seeing Agile as a religion, this is what makes Agile so effective. Using Agile as the flexible framework it is, continually learning and adjusting it to meet your team’s changing needs and goals within a specific context.
Agile as a Religion
Devotion to Agile
When somebody completely believes in Agile, they often overlook many of the realities of their work situation when first implementing it. Agile, just like religion, can become a multifaceted phenomenon that encompasses beliefs, practices, rituals, and values centered around the sacred or divine. Not providing evidence and rationality when first adopting any approach will either slow down the adoption or, worse, ruin your chances of transforming the group.
Downsides include:
Decreased Creativity and Enthusiasm: If the process is too rigid, then it becomes sacrilegious to deviate from it. When combined with a weak or non-existent continuous improvement loop, this devotion can be disastrous. Teams and the people who make them up desire and need the ability to evolve and experiment. Nothing kills the enthusiasm of a person faster than never letting them try anything new or different. Even Agile itself has evolved over the years.
Good process, bad outcomes: The process should support the outcomes desired by the business. I would rather have the worst process ever with good outcomes than a great process with bad outcomes. Agile exists to help further the goals of the business (along with many other positive reasons).
Rejection due to poor initial results: Results may suffer if the people responsible for producing those results aren’t behind the process. If people find Agile too constricting, they will either half-heartedly adopt it or, worse, may even fight against it. Some resistance is to be expected, but without enrolling the team, it will be difficult to build a high-performance team.
False Beliefs
Each one of the following was taken directly from initial conversions with a team I was working with to adopt Agile.
Because we are using Agile, we don’t ever have to write any documentation. [See The Best Practices for Documentation.]
Because Agile supports cross-functional teams, everyone must know how to do everything. That is why we are all learning to code in all the languages instead of producing features. [See cross-functional team section.]
We don’t have to estimate since we started using Agile.
We just get work done when we can; Agile doesn’t do planning.
We used to plan, but Agile says planning is a waste of time.
Like much misinformation on any topic, Agile has a common set of false beliefs. The most prevalent are those that contain a bit of truth in them. For example, the false belief that Agile teams never write documentation comes from the Agile manifesto. (You can see how intense these conversations become with documents titled “Manifesto.”) Yes, the focus is on working software over comprehensive documentation. Yet, nowhere does it say that documentation is bad or not needed, and the belief that Agile doesn’t document anything is incorrect.
Usually, when working with new teams, I let a lot—almost everything—slide in the beginning. The one exception is when the team starts to parrot false beliefs. I meet false beliefs head-on, usually stopping all conversation to provide a bit of education.
Methods to Adopting Agile
Slow and steady – This is my favorite approach. Typically, I jump in wherever the team is in their maturity and layer in one Agile concept at a time. Some examples and ideas include hiring for missing roles such as Scrum Master or Product Owner, adding missing ceremonies one at a time, or adding components, such as the concept of estimation, one at a time.
Fast and abrupt – I reserve this approach for when there isn’t much worth saving within a team’s process. Just throw away everything the team is doing and start over. The best way to start over is to cancel all meetings and redefine them with ceremonies to reestablish the relationships inside the team and with outside human interfaces.
Team first – Start with a single team and take the extra time to set up everything correctly. Then, move team by team throughout the organization.
Company-wide – This approach requires executive buy-in (for real, not just for name’s sake). Remap all the whole organization’s processes to follow Agile. Besides the executive buy-in, a couple of things make this approach hard. For example, new roles will need to be hired, such as Product Owners and Scrum Master. If the company is of any size, some scaling framework, such as SaFe or Scrum at Scale, will be required. Note that scaling frameworks are tricky because less people are familiar with them, and they sometimes require additional roles (in addition to Product Owners and Scrum Masters), and may require a considerable amount of change within the organization.
Why Agile Isn’t (and Shouldn’t Be) a Religion
I am not sure even the founders thought Agile was perfect when they created it. The founders had lots of business and technical experience and were not trying to create the perfect system but rather create a better system for sustainable development. When they met, development projects were out of control. Having worked on projects 20 years ago, I can tell you from firsthand experience that it’s amazing any project finished, let alone finished on time.
Since the inception of Agile, there has been a lot of refinement and, hopefully, a lot more innovation will occur. The ability to change and adapt, unlike religion, is what makes Agile so effective. Even though Agile is relatively new, it has adapted in meaningful ways.
For instance, it has survived:
Being used outside of software development. The manifesto starts out, “We are uncovering better ways of developing software by doing it and helping others do it. Through this work, we have come to value…”
The pandemic and the ubiquitous existence of remote teams. The manifesto’s first statement is, “Individuals and interactions over processes and tools…”
Agile has expanded beyond software development. It experimented with ways to scale. It has adapted to new concepts such as DevOps. It has evolved to incorporate culture and mindsets. It now has formalized certifications and training. Because it is changing and adaptable, Agile will probably survive as AI changes virtually everything. I look forward to future changes and modifications.
Conclusion
When considering your approach and relationship to Agile, it’s important to recognize that Agile should not be treated as a rigid doctrine but as a flexible framework that can be adapted to meet the needs of your specific context. Agile is just one of many methodologies that have been developed over time to improve the way we organize and execute work. It wasn’t the first attempt, and it certainly won’t be the last.
Throughout history, technological advancements have continually reshaped business processes. From the era of mainframes to the advent of AI, each new wave of technology has introduced significant changes and new paradigms approximately every decade. These shifts remind us that clinging to any single framework without considering its evolution and adaptation is short-sighted.
Historians and business scholars have had time to study these technological and process changes, revealing valuable insights into how we can better manage and adapt our work. Reflecting on the works of influential thinkers like Eliyahu Goldratt and Peter Drucker, we can draw lessons from their forward-thinking approaches. They remind us of the importance of remaining open to new ideas and the value of learning from past methodologies.
By understanding and appreciating the journey of technological and process innovation, we can better appreciate the role Agile plays today. It serves as a guide, helping us navigate the complexities of modern work environments. However, it’s crucial to remain adaptable, continually learning and evolving our approaches. Letting the constraints of today confine what is possible in the future would be a mistake. Instead, we should leverage Agile as a dynamic tool, inspired by past wisdom and geared toward future possibilities.