MMS • RSS
- A dogmatic approach to Agile, such as prescriptively adhering to the Scrum Guide, is not Agile and is a serious antipattern
- Internalizing the Lean Agile Values and Principles is key to a successful Agile transformation
- Organizational complexity demands a multi-framework approach tailored to the organization’s unique culture, goals, and issues
- Theory must be informed by practice
- Agility is a means to an end, not the end itself
The Dangers of Dogmatism
But isn’t Scrum all I need to do to be Agile? Maybe, but not likely as no single framework is the answer to any complex organization’s Lean Agile Transformation, especially when reaching beyond the borders of IT to encompass overall organizational business agility.
Still, there are those dogmatists and framework salesmen that will claim that Scrum will solve all your team level problems or that their Scaling framework fits all organizations’ scaling needs. While gains will be realized, the truly transformative gains that launch your organization into the high-performance 200x better than their competition requires a pragmatic Agnostic Agile mindset-driven approach that is truly customized to your teams and organization as a whole.
So why is that? Well first let’s look at how a dogmatic, one-size-fits all approach hobbles an organization’s Lean Agile Transformation. The key reason is that it doesn’t recognize or address your organization’s uniqueness. Even in the same industry, organizations have their own unique history, culture, challenges and goals.
An organization does itself a disservice by implementing in its entirety a given framework just because they have been convinced by some coach or framework salesmen that this works everywhere else so it’s perfect for you be it the Spotify model, Scrum, SAFe, LeSS, or whatever framework they are pushing.
Have they spent any time truly understanding your history, culture, challenges, and goals? Yahoo and Google are both in the search engine and information aggregation business, but both are very different organizations. Furthermore, even within the same organization, groups and departments may have very different needs. Maybe the widget department should use Kanban while the grommet department uses a Scrum/XP blend.
Secondly, a dogmatic, one-size-fits all approach does not allow for a healthy, unfettered Lean Agile evolution and maturing at both the team and organizational level. For example, a classic Command and Control enterprise may initially only be ready for a highly structured Scaling framework like SAFe; however it may evolve to the point where a far less structured model, such as Scrum@Scale or the Spotify Model would be more appropriate. In this case the organization needs to be made aware of lighter weight approaches and aided in transitioning to the best approach for them.
Additionally, a dogmatic, one-size-fits all approach squelches innovation, learning and runs contrary to the Agile Principle of “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly”; for a dogmatic approach constrains the ability both at the team and organizational levels to “adjust its behavior accordingly”. Sadly, a team’s natural evolution and maturation can be seen as a violation of the playbook or framework guide and be nipped on the bud by a dogmatic coach who forces the team to do Agile by whatever book is their ‘bible’. Insisting that this is a ‘SAFe Shop’ and ‘we only do what is in the playbook’ and that anything else is ‘Scrum-Butting’ squelches any evolution and does the teams and organization a profound disfavor.
A dogmatic framework-centric approach also squelches team and organization independence by making the team and organization dependent on their framework coach to make sure they are doing the framework right. Any deviation is seen as a failure that has them running back to the framework coach for a framework refresher to get them back on track. This fuels a cargo cult mentality where the team or organization sees following the framework guide as being Agile with little or no understanding of the Lean Agile Values and Principles underpinning the framework.
Also lost is the fundamental truth that Lean Agile is a mindset not a specific framework and is about creating an empowering culture above all. It is no accident that the first value listed in the Agile Manifesto is “Individuals and Interactions over Processes and Tools”.
Now that we have seen why a dogmatic, one-size-fits all approach is a Lean Agile transformation antipattern and is actually not Agile at all, we will look at what an Agnostic Agile approach will do for us.
We will do this by looking at how key Agnostic Agile principles facilitate and accelerate both the organization’s transformation as well as its Lean Agile evolution. Note this article contains my own interpretation and commentary on these principles. The principles with their original wording can be viewed here.
Principle 1: To put my customer first, making them independent
Besides tailoring a multi-framework approach that best fits the customer, putting the customer first means making the team and organization independent of the coach by teaching them to fish.
Healthy team evolution means that they go through three phases, commonly referred to as Shu-Ha-Ri. This evolution can also be applied to the organization as a whole.
- In Shu, the team members learn the frameworks they will be using. This is when a prescriptive approach is appropriate and called-for.
- In Ha, the team is comfortable with the frameworks and starts being Agile. They are internalizing the Lean Agile Values and Principles and use that awareness to ‘break the rules’ or deal with grey areas in a way that is true to the Lean Agile Values and Principles.
- In Ri, the team is truly independent and self-coaching to the point where the specifics of a given framework become increasingly less important as they apply the now fully internalized Lean Agile Values and Principles to tailor and blend the frameworks to create a Lean Agile ecosystem unique to their needs, goals, environment and culture. This is how Scrumban and the Spotify model came to be. The team or organization is no longer practicing Scrum or SAFe, but are practicing OurAgile.
While the Agnostic Agile Coach understands that one needs to teach the frameworks, they know that a mono-framework approach is not optimal and that the Lean Agile Values and Principles must be taught in conjunction with the frameworks. Furthermore, they will emphasize that the values and principles are far more important that the specifics of the frameworks in question. Personally, I always advise team members and managers that the best approach to any problem, the best behavior in any situation, or the best answer to any question is the one that is truest to the Lean Agile Values and Principles.
Once the team is comfortable with the framework and understands the importance of the Lean Agile Values and Principles, the Agnostic Agile Coach will mentor and coach the team and organization along the path of internalizing the principles and values. This facilitates their evolution to the Ha phase. The coach will challenge the team on their rational for breaking the rules or approach to grey areas to ensure that they have applied the values and principles in their decision making process as opposed to getting sloppy.
Eventually the Agnostic Agile Coach will know that the team has truly internalized the values and principles and their decisions and approaches are true to the values and principles. The coach has taught them to fish and can ride off into the sunset as the team is now self-coaching. A good coach fires themselves, a bad coach becomes a permanent fixture and creates an unhealthy dependency on them.
Principle 2: To do my best, complementing theory with practical experience
Do your coaches have practical experience? Your trainers? Your Scrum Masters? While book knowledge of the various frameworks is necessary, it is not sufficient for those who train, facilitate, mentor or coach. Practical experience tells you what really works, where the landmines are, what helps, what hinders, and where the rubber meets the road. Together the blend of theory and practice reduces the risk of doing harm and increases the ability to understand the customer’s unique aspects in order to craft an optimal approach for that customer.
As an organization you can only benefit by your coaches, Product Owners and Scrum Masters having both a solid grounding in Lean Agile best practices as well as practical Agile experience. They will know what works and when to do it by the book, when not to and how to respond to situations where the framework used has no ready answers.
It is a concern that a team can be guided by someone with no experience and two days of training (CSM, PSM I); it is interesting that organizations that would never have placed an inexperienced person in the role of a waterfall PM, will place an inexperienced person in the role of Scrum Master. Even more of a concern is that someone with four days training (SPC4) could be leading an enterprise-wide scaled Agile transformation. In many cases the trainer who certified the Scrum Master or SPC4 isn’t required to have any practical Lean Agile experience either. This is tantamount to teaching someone how to drive without ever having driven. Only if the trainer has practiced Lean Agile in the real world can they impart the knowledge required to learn practical, in the trenches Lean Agile techniques as opposed to dogma and Lego games.
Principle 3: To tailor agility to context
As discussed in The Dangers of Dogmatism section, an organization is unique, so it both deserves and requires a Lean Agile approach that addresses and respects the organization’s uniqueness. This does not mean the Agnostic Agile Practitioner tolerates a lack of Agile growth, or faux Agile, however, the practitioner realizes that organizations cannot progress at the same rate and must be guided in a way that does not traumatize the organization, teams, and individuals by forcing too rapid a change. The practitioner’s experience and training lets them know when to push and when not to. That experience also allows the practitioner to tailor a blend of Lean Agile techniques that will work in the context of the organization’s reality.
Principle 4: To understand hindering constraints and work to remove them
Understanding the unique context and culture of the organization is key here, as is respecting where the organization, team or individual is. Respect is important as the organization, team and individuals are getting through their day as is and have learned to survive and even thrive in their current environment and culture where wastes and other dysfunctions have become normalized and internalized. Brain science teaches us that small changes are far more likely to succeed.
The Agnostic Agile Practitioner understands all of this and crafts their approach to removing constraints appropriately knowing when to tackle them head-on and when to flow around them like a stream around a rock. They can answer the ‘What’s in it for Them?’ question and ask them to ‘Help Me Help You’. Their pragmatic, agnostic mindset helps them avoid the dogmatic prescriptive ‘ram it down their throats’ approach which will hobble any transformation.
Principle 5: To share, learn and improve
This is key to the growth of the individual, team, and organization. An Agnostic Agile Practitioner will work to create an environment, mindset and supporting processes that enable sharing, learning, and improving. Team and multi-team retrospectives, formal and informal training, guilds, hack days, show and tells, and any other means of learning and sharing those learnings will be pursued. This creation and sharing of knowledge fuels and facilitates an organization’s Lean Agile transformation.
An Agnostic Agile Practitioner will not feel threatened by another coach or practitioner who is more experienced or skilled, rather they will enlist that person as a mentor. No matter how skilled and experience, an Agnostic Agile Practitioner knows there is something that can be learned from any person they encounter no matter how ‘junior’ that person is. By learning and growing their knowledge, they increase their value to their organization or customer.
An Agnostic Agile Practitioner never presents themselves as the guru, for doing so creates a barrier to the sharing of knowledge and the growth of not only the team, team members, but the practitioner themselves.
Principle 6: To respect frameworks and their practitioners
Agnostic Agile respects all frameworks, disciplines and their practitioners, as it is those frameworks that provide us with the tools we need to facilitate our team’s and organization’s transformation, as well as creating an empowering culture.
The caveat is that the mono-framework practitioner must have an open, pragmatic attitude toward other frameworks and a willingness to work with practitioners of other frameworks forming multidisciplinary teams with the sole goal of doing what is best for the client and that respects where the client is in their organizational evolution. The Agnostic Agile practitioner will dialogue with the mono-framework practitioner in order to help them be more open to working in a multi-framework environment. By moving everyone to a more pragmatic, mutually respectful attitude, the organization benefits by having everyone focused on its transformation as opposed to being engaged in framework wars.
Principle 7: To acknowledge unknowns and seek help
An Agnostic Agile Practitioner is humble enough to know what they don’t know and when to go to other coaches and practitioners for help and advice as well as when to step aside and let another more experienced coach or practitioners step in if it is in the customer’s best interest. The Agnostic Agile Practitioner also knows when a framework specialist needs to be brought in, just as a Family Doctor knows when to refer a patient to a specialist.
Principle 8: To never mislead and to never misrepresent
In all ways, an Agnostic Agile Practitioner acts with honesty and integrity in the best interest of the customer, team and individuals they interact with. If they honestly overestimated their ability, overlooked an option, or made an honest mistake, they will own it, admit to it and make amends. Part of acting with integrity is not going along with a customer’s desire to pretend to be Agile in order to meet some outside requirement or executive directive to be an Agile shop when they personally have no intention of actually being Agile. Honesty and integrity are all-important in order to build the trust and gain the buy-in necessary for a successful transformation.
Principle 9: To remember that agility is not the end goal
It is a means to an end and there may be other means to the same end that make more sense for the customer’s growth and overall heath. The Agnostic Agile Practitioner assesses the organization’s culture, goals and issues to determine if other approaches or disciplines are more appropriate. For example, in fear-based or ultraconservative organizational cultures a Lean Agile approach is doomed to fail without first addressing the underlying psychological and sociological issues. In these cases, the organization is better served by bringing in organizational change and organizational behavior specialists prior to embarking on its Lean Agile transformation.
At the end of the day, the end goal should always be what is best for the customer, even if that means handing them over to other specialists and walking away.
Principle 10: To acknowledge that dogmatism is non-agile
I have already covered why dogmatism is not Agile and a violation of both the letter and spirit of the Agile Manifesto in the first section of this article. The dangers of dogmatism to the organization have also been covered.
The one thing to add is to warn against being so dogmatic about being pragmatic and agnostic that you view and treat mono-framework dogmatists with distain. An Agnostic Agile Practitioner accepts where people are and that they are sincere in their belief that they are being Agile. So it is necessary to treat them with the respect that is due to any person and engage in constructive and respectful dialogue using the Agile Manifesto as the common ground.
Principle 11: To recognize that there is more to agile than agile
This one is related to principle 9. There are many fields an Agnostic Agile Practitioner can and should draw upon if the situation warrants it. These include Lean, Design Thinking, Management 2.0 and 3.0, organizational behavior, psychology, etc. A holistic, multimodal approach that best serves the customer is the order of the day.
Principle 12: To give to the community as it has given to me
An Agnostic Agile Practitioner acknowledges that the community has given them knowledge and support over the years. In their gratitude, they give back to the community by writing, posting, mentoring, and offering support as needed. They make time for their fellow practitioners and for those who wish to embark on their Agile journey. This benefits the customer as the practitioner grows their own knowledge in the process of giving back, plus the overall level of knowledge available in the Agile community grows.
An agnostic approach to Lean Agile will accelerate an organization’s Lean Agile transformation by crafting an approach that addresses that organization’s unique culture, goals, and issues. Furthermore, by focusing on the Lean Agile values and principles as opposed to specific frameworks, an agnostic approach aids the organization, teams and individuals develop and internalize a Lean Agile mindset. The combination of a pragmatic, customer-centered approach and the emphasis on ‘being Agile as opposed to doing Agile’ avoids the dangers of a prescriptive dogmatic framework-centric approach.
For more on the Agnostic Agile approach, contact the author as well as visit the website.
About the Author
Tim Guay is well-versed in Lean Agile best practices with a proven track record as a practitioner, trainer and coach. He is experienced in introducing Agile and Lean into organizations, providing Agile and Lean training and coaching, as well as introducing DevOps best practices. He has been a practitioner, Agile trainer and coach to a wide-range of organizations from start-ups to Fortune 50 corporations since 2002. Tim has presented at conferences, developed courses and published articles on a wide-range of Lean Agile topics. He sits on ICAgile’s DevOps Track Certification Committee as was an early signatory of the Agnostic Agile Manifesto.