Reblogged with permission from Michael Küsters, the original author of this content, as a contributor to blogagility.com. Originally published on LinkedIn January 13, 2018.
One of the common arguments for any agile framework is “Just try it – it works”. I’m not going to argue whether they do, (I believe that done right, the famous ones all do). Instead, I would like to explore why practices or ideas which are so different and seemingly “wrong” from one framework’s perspective can still be “right”.
So many facets
Let’s start with an example: Should you sprint?
The Scrum zealot’s perspective
If you don’t use Sprints, you’re not doing Scrum, so it’s essential to sprint. Reasons brought up against sprinting are usually impediments to value delivery that the organization does not want to deal with.
The enlightened Scrum practitioner’s perspective
There are a lot of good reasons for sprinting, such as creating a mutual understanding on what and how value will be delivered. Reasons for short sprints include: Faster feedback, easier adaption, more learning. Reasons for longer sprints include: Reducing the amount of interruptions, giving stakeholders a longer perspective. As sprints are a core structure of Scrum, abolishing Sprints means abolishing Scrum.
The Kanban zealot’s perspective
If you do use Sprints, you’re batching up work and creating a wasteful queue. Reasons brought up to argue for sprinting are usually impediments to value flow that the organization does not want to deal with.
The enlightened Kanban practitioner’s perspective
It’s totally okay to organize work in sprints to create some level of predictability, but it might not make sense to batch up work or defer value delivery to the next iteration. Frequently creating short-term plans, collecting feedback and improvement make a lot of sense, but you don’t have to sprint for that.
The Project Manager’s perspective
Projects are typically set up when it’s already clear what will be done in which timeframe. Slicing this work into portions is not important. Delivering the project’s value is. If teams decide that they want to sprint, this is okay – but much more important is that they stay on track.
Who is right?
Everybody is right. Based upon their perspective, every statement is correct. The way I have phrased the positions in this example, some perspectives are mutually exclusive and even contradictory. This is what I call the “ambivalence of truth“.
Who is wrong?
Especially zealous people seem to think that they can “win” the case for their framework by proving others “wrong”. Not understanding or ignoring the ambivalence of truth leads to a severe dysfunction: ignoring the positive evidence for things that do not align with one’s own perspective. This is also called observer bias and will lead us to draw wrong conclusions.
Even worse than trying to prove others wrong by insisting on being right, we do become wrong by being right.
Conclusion
As agnostic agile practitioner, I understand that truth is ambivalent. Mutually exclusive concepts about organizing the work can be equally true – simultaneously! I do not spend time to discover problems that the different frameworks might pose based on a certain perspective. I focus on how and whether they provide an advantage to my client in their specific situation. Being agnostic to agile frameworks, I am comfortable of combining seemingly contradictory practices from different frameworks. The outcome for my clients is more important than conformity to a pre-packaged solution.
Find out more about Agnostic Agile at: http://agnosticagile.org/
blogagility.com 