“Agile Scrum”​ – It’s doing more harm than good!

****** All my articles are published simultaneously on LinkedIn as well:
https://www.linkedin.com/in/fluxed/ 
******

 

Almost everyone within a software industry must have heard about “Agile” or “Scrum” or both on every project management context. People often use them interchangeably to refer to something that matches with their confirmation bias. It’s appalling how both are misinterpreted, tailored to avoid change and lied about. It causes irreversible damage to a company’s growth, revenue and prosperity guided by employees who may have no idea what “Agile” and “Scrum” actually stands for.

Few common misinterpretations of “Agile Scrum”

  1. Scrum will make you Agile
  2. If you want to do Agile, start with Scrum
  3. Scrum is a great training wheel to become Agile
  4. Scrum is a branch of Agile Project Management

Each of these misinterpretations will be explained later in this article. Feel free to scroll down to that section, after all it’s part of your daily social media read. Although I would strongly suggest you read the following material before that.

Scrum isn’t about “Agile”

If you believe in Shu Ha Ri way of learning, please do the following as your “Shu” step –

  1. Open the following PDF online (No it’s not a phishing link, it’s the Scrum Guide)
  2. Search the word “Agile/agile/AGILE” within it.
  3. Note down the number of times it appear in the PDF.

The number of time it appears here = The amount of truth you have been exposed to when you first heard about “Agile” in your career.

Now, search for “Goal” in the same document. If there’s no new version of this live document since I started writing this article, “Goal” should appear 37 times.

Scrum is about setting a Goal which is the base of every discussion, development and mechanics to achieve it in a time box, Sprint. Then we inspect and adapt the goal.

If that makes us “Agile” – it’s simply a useful byproduct. It’s not the intent and reason why a lot of teams fail in establishing basic agile mindset/attitude within a Scrum implementation. They are simply chasing the wrong intent. Failing that they end up blaming Scrum and Agile. It’s doing more harm than good.

Agile (noun) vs Agility (noun) vs Agile (adjective)

This may sound like “Old shit rehashed”. In fact it is, but with a twist. It has been mentioned, told and explained many time by many professionals in several occasions. Feel free to scroll down to the next section if you heard this before.

Agile (noun) – Usually refers to the Manifesto for Agile Software Development. These are a selection of carefully worded statements which radiate Simplicity during collaboration.

Agility (noun) – Refers to the true essence of the above, it’s values and principles. This is misinterpreted often, as we cannot measure this by numbers or metrics. Can you measure your principles and values?

Agile (adjective) – This is misinterpreted in way many cases and by far the most useful way we should approach a solution. To be agile doesn’t mean “fast”. It’s about being “adaptable” on our approach to achieve a focused goal with no set rulespractices or methods. Turn when you need to, where you need to and how you need to – but focus on the valuable outcome.

Can Scrum be the way to Agility?

Sure. Scrum can be one of the ways but being a framework, it doesn’t include any method, practice or techniques. This is on purpose – because, again, it’s not about making us Agile.

Scrum is about complex product development where, at most part, the output is unknown but have a possible outcome as a goal.

“Complex” can be subjective. Easiest way to know when to use Scrum is asking this question to yourself – “Do we know what we are building?“.

If No, you definitely need Scrum. Forget about being agile, you have no idea what you really want to build. You have a clear “Why” in mind and you need to get there by any mean possible.

If Yes, there are 2 ways to interpret –

First – may be you think you know but you don’t. How sure are you?

Second – may be you are right. Then you probably don’t need Scrum.

Clarifying the Misinterpretations

1) Scrum will make you Agile

You can follow Scrum by book, exactly as it says on the Scrum Guide. You can have dedicated roles as it suggests. It is still possible to be not be agile. Here’s how the Scrum roles can be misused –

Product Owner (PO) – Starts dictating the product roadmap without consulting anyone. Becoming a Stakeholder (not customer) proxy with no real input based on data or own analysis.

Scrum Master (SM) – Starts managing people rather than the flow of work, thinks of him/her as the team’s manager and collect stats on how many hours the DTMs are working.

Development Team Member (DTM) – Starts dictating the technical aspects way before the intended value is established, disregarding PO or SM’s suggestions and creating an anarchy which leads to well engineered product which no one will ever use.

2) If you want to do Agile, start with Scrum

If doing “Agile” is the goal, the person needs to read the Manifesto few more times before saying those words. You cannot do “Beautiful” or “Nervous” or “Green” or “Strong” or “Happy” or “Surprised” or “Spicy” – wait where was I? Of yes, stop doing things which are descriptions. And if you are doing the nouns, I would be very concerned on a very different level.

“You know” – No, I don’t know. Unless we start using the correct semantics, we should stop discussing anything around Agile or Scrum.

3) Scrum is a great training wheel to become Agile

This is by far the most sophisticated way to sell Scrum. Selling is not bad, although selling a solution that doesn’t help remove the core problem is wrong.

I am a servant leader and I am freaking proud to be one. Although, I would never recommend anyone to implement Scrum just because they want to become Agile. Everyone should suggest a solution which is appropriate to the problem. You call yourself a Scrum Master or Agile Coach or Enterprise Superstar.. just don’t sell a hammer when they need a scissor.

Most companies we work for do know what they want as they have a huge requirements pool (1000 Tickets on a Jira backlog) already setup. They intend to break them down in chunks as “Sprints” and call it a feedback cycle. If they have everything prepared, may be a well governed Waterfall is a better choice isn’t it? Why bother with the names like Scrum or Agile or similar?

If you want to become Agile, focus on value and the value stream.

4) Scrum is a branch of Agile Project Management

No comments, except, on behalf of all true Agile practitioners –