The following statements are often mentioned:

• Scrum-but is bad. You should stick to Scrum rules, otherwise you are doing it wrong.
• Scrum coaches are often dogmatic.
• There is no right or wrong way to do Scrum. It is all about inspect and adapt, even for Scrum rules.
• My Scrum-but way is working very well.

I could continue, specially when talking about certain details. Such as, does it make sense to have 5 Scrum teams with 5 Product Owners delivering a single product?

I’m usually placed in the camp of religious-like zealotry. That is interesting, since I don’t believe in any religion. I do believe in proper arguments and evidence-based information. Therefore, above statements and accompanying explanation don’t provide any meaningful information.

Instead, it would be much more interesting to properly explain why certain aspects in Scrum do not work in certain contexts. We could all learn from that. I would be the first to embrace such improvement or alternative to Scrum. In such case, I still reserve my right to open-mindedly judge whether argumentation and evidence makes sense. The usual questions I would ask:

• What is the actual result of your Scrum-but? Are you continuously improving, delivering really done high quality increment with useful features in few weeks or shorter to real users? What is the lead time (time from a request to usage by a user)?
• Are you sure that the reason why Scrum is not working at your place has nothing to do with organisational dysfunctions?
• If your Scrum-but is working very well, please define “working very well”.

These questions are NOT meant to defend Scrum, but to defend result of doing Scrum properly. In fact, this could be applied to other frameworks too, and therefore judge their value. Unfortunately, in all of the discussions and posts I have seen so far, either explanation or the actual results are lacking. It is interesting to observe that discussion is either stopped or sidetracked whenever actual results are questioned. A typical example is teams and coaches claiming to do Kanban with a lot of fancy columns on their Kanban boards:

How long is your maximum lead time? A: We don’t know exactly, but it is about 6 months and slowly improving.

How long is going to take before you get to 4 weeks or less? A: No idea.

I have nothing against Kanban, but I have everything against taking the easy road for the sake of calling yourself Agile, and somehow neglecting actual results in the process. I do have something against some other frameworks and methodologies which lack evidence of being useful and still use words as “proven” as if it actually means something.

Another pattern in these discussions is the argument of being practical. It is often said: “Our organisation is not yet capable of following Scrum in a proper way”. I think that probably no traditional organisation was judged as being capable of doing Scrum 15 years ago. Nevertheless, today many of them bare the fruits of this seemingly impossible goal. Despite this fact, today others still compromise a lot with minor or no actual improvement as a result.

One can only be named dogmatic if one is not open to possible improvements. Embracing Scrum framework in most situations, simply because it provides tremendous improvements relatively fast, has nothing to do with being dogmatic. Also, sticking to rules has to do with evidence-based strong correlation between lack of actual results and compromising with already simple rules.

For me, “our Agile implementation is working just as fine” is a meaningless statement. Is your organisation achieving something great (and what is it?) or just being mediocre as always?

So, I’m fine with being called dogmatic, religious-zealot or sometimes completely opposite of both, but let’s get over that and talk about real achievements unless you are ok with mediocre. I’m not.