Scrum: Facts vs Fiction.

Webster defines a methodology as a

a body of methods, rules, and postulates employed by a discipline : a particular procedure or set of procedures.

Scrum is a methodology. Therefore it is (and I paraphrase Webster's definition here) "a set of tactics used for ensuring open communication in the hope of reducing the risk associated with delivering something of value".

Every methodology/framework is an attempt at reducing some sort of risk.

Scrum is no different but as is the case with some of our fellow homo-sapiens, following cultivated hype is easier than realizing that, at best, methodologies and frameworks are suggestions based on an average derived from multiple experiences. Summary: pay heed to the crowd but make sure to find your reason for being a part of it.

Things about Scrum I learnt the hard way.

Thing # 1: Scrum does not necessarily make software delivery faster.

Yes, it does not. The words Scrum and Speed start with the letter 'S' but that is the extent of their similarities. The terminology used in Scrum creates the impression that there is a built-in benefit of speediness in it (which eventually may be true but that's a second-order effect). Words like sprint, story points, velocity, cycle time and lead time cement this mentality, especially if the methodology is looked upon as a standard operation procedure.

I prefer to think of Scrum as a sieve and, ideally, it helps Product Managers in separating what the customer wants versus what is noise. Of course, if we know what we truly need to focus on, our work will likely get completed faster.

Additionally, over a while, once teams have experienced Scrum, they will find procedural areas where improvements are possible (e.g. automating regression tests or using CICD tools for automatic deployment), all of which decrease time spent completing work.

Thing # 2: Scrum demands a cultural shift.

Whoo! That's a big statement. Do we have to change our culture if we want Scrum to be successfully adopted? That's asking for too much, isn't it?

First off, I want to argue that when we read the word culture, we should not imagine a nebulous cloud of people and their behaviours, mixed with corporate standards and edicts. Rather, reduce the scope of your imagination and focus entirely on the default behaviour of your teams, as and when they are tasked with completing something. For example, does the Business Analyst use a requirements template with sections upon sections of details (some of which might not be necessary right away), or rip a page from his notebook and scribble down a user's ask? For such a BA, asking them to consider User Stories to document intent is an example of a culture shift.

Thing # 3: Scrum also demands a pan-organization cultural realignment.

Many a time, as a Product Manager, one faces a situation where those who give us requirements don't follow (or want to follow?) the spirit of Scrum. It feels, unfortunately, like fitting a small glove on a large hand.

Inconsistency in approaches used by, what we call, business and technical delivery teams will eventually turn into a litany of broken communications, unrealistic expectations and hurt feelings on all sides.

Thing # 4: Scrum training and certifications are NOT AT ALL representative of one's understanding of it.

When I took my first official Scrum training course, I was expected to attend two 8-hours online sessions, at the end of which, a simple exam was administered and I became a Certified Scrum Master, but did I truly become Scrum-ified?

Scrum cannot be learnt from a book, but in the heat of battle. A certificate does NOT make you a master at it. It only shows you know the jargon but to understand it truly, teams have to un-learn traditional tactics. For example, a shorter focused meeting is better than a longer aimless one or getting just enough detail about a feature (and delivering it) is preferable to waiting for every known nuance to be known, documented and approved before work can begin.

Thing # 5: Adopt Scrum-prescribed activities and end up doing Agile versus being Agile.

First-time adopters of Scrum usually start behaving like Scrum-Soldiers. They have stand-ups, sprint planning, backlog management and retrospectives down to a science but is that what they should do? It feels like they are playing Scrabble but using numbers for spelling their words.

Remember, the tactics we use (doing) are not the same as the strategy (being) behind them.

Thing # 6: Agile or Scrum is not a panacea for weak delivery.

They are your friends and mentors. They have your best interest at heart. They want to teach you to fish, not fish for you. The fishing rod, the tensile strength of the fishing wire and the quality of the bait used are decisions you have to make. If the outcome of the decisions made DO NOT realize the expected benefits from Scrum, take a step back and critically analyze your team culture, their default behaviours and their appreciation of Scrum's underlying philosophy.

I write to remember, and if, in the process, I can help someone learn about Containers, Orchestration (Docker Compose, Kubernetes), GitOps, DevSecOps, VR/AR, Architecture, and Data Management, that is just icing on the cake.