Don't go "tilting at windmills"

A recent one of those nonsense posts (and I don't mean to pick on the specific one, as this is quite common), attempting to create a sort of dichotomy between Scrum and Kanban made me to remember what I believe to be one of my biggest learnings in my career (so far). I like to think of it as don't go "titling windmills", a literary expression that goes back to the the classic from Miguel de Cervantes, Don Quixote:

[Don't go] fighting imaginary enemies or confronting imaginary problems.

The matter of the referred post is an imaginary problem, as Scrum and Kanban have been routinely being used in combination, but this isn't even the point of my writing here. I would rather take it levels of abstractions up, and talk in general about the often pointlessness of 'labelling' things.

Don't get me wrong here, I do think it's important to give credit where due. On top of that, and to use a quote I like a lot, there's such a thing as better ways to achieve the outcomes we are aftet: 

“We’ll prioritize outcome over process, while recognizing that some processes get you better outcomes”. - Matt Wallaert

So the point is really more nuanced, it's about in fact embracing nuance and perspective, not letting change to become a kind of "windmill" that people will "tilt to"… I've come to the conclusion that's what may happen at the moment we get too hanged on naming something, or focusing too much on the concepts and where they come from, as opposed to just focus on the challenge in front of us, using both experience and inspiration to do something about it. Let's worry with the giving credit where it's due next.

- Hey, remember when we did 'X'? Did you know that 'Y' is where it comes from? (Perhaps adeed with a deeper reflection that could sound something like: - Have you seen how it's not quite the same as when we had that useless exchange where both of us were defending something we just happened to know more about than the other?)

I am speaking here out of experience, as a recent case study I shared with the Kanban community (yes, I have my own biases, but I hope my post proves it's beyond the real useful discussion). In that case, I never spoke (at least not without context) about introducing the metrics, or the signals, the reflection mechanisms, as adopting Kanban practices. I focus on what we are trying to achieve, which is iterate more often as a means to increase our chances to get to better outcomes. By the way, most of the teams related to the case do happen to use Scrum as their tactical framework to deliver stuff (some have figured out some other way, that looks more like a simple continuous delivery, so at least "Kanban-like") – again, not quite an useful discussion, not at all a kind of "hill I'd be willing to die on…".

Ultimately, it would be all much more useful if we all would focus on what truly matters (such as):

Solving problems. Making things better. Getting to better outcomes (where our perhaps better ways are a means to that end). 

Much better focus, right?

By Rodrigo Sperb, feel free to connect, I'm happy to engage and interact. If I can be of further utility to you or your organization in getting better at working with product development, I am available for part-time advisory, consulting or contract-based engagements.