The Traditions of Men

Ye leave the commandment of God, and hold fast the tradition of men.  Mark 7:8 (ASV)

I never in my wildest dreams would have thought I would ever write a post  “defending” Scrum especially considering that I’m not a Scrum advocate (ask the folks I work with, I think they’ll confirm that 🙂 ). Then again, Scrum definitely doesn’t need me to come to its defense and yet I’m compelled to share a few thoughts down – at least for posterity’s sake.

Every week I come across a post indicating why Scrum did not work for a team and how they switched (or evolved as some describe it) to something else.  (I come across similar posts on diets and soccer formations as well). First of all, I’m happy that the teams found something that worked for them.  I hope that if they wanted to work in Agile-based manner, their new approach allows for that.  After all, “we are uncovering better ways…” aren’t we?

However, I find it irresponsible for these people (and other Agile thought leaders) to blame Scrum for certain things that occur especially when these things are really not Scrum things.  It’s important to remember that Scrum is a framework that needs to be filled out if software is actually going to be developed and delivered.  Scrum, via the Scrum Guide, doesn’t provide much (explicit) guidance on how to actually develop and deliver software.  It provides a framework for managing the software development process.

Before you begin to debate this with me, let’s simply agree that the Scrum Guide is the official definition for Scrum.  In my opinion, any other text on Scrum is the author(s) description of how the framework was implemented and what additional techniques or practices were found beneficial as the framework was leveraged. Unfortunately, some of these techniques (promoted by Agile and Scrum thought leaders) have over time become characterized and adopted as Scrum rules when they are really techniques used with Scrum.  They are traditions.  Let me provide a few examples.

Estimation

Scrum currently says nothing about how estimation should be done and yet it would seem that Story Points estimation is considered THE Scrum estimation approach.

Delivery Cadence

Scrum requires that a “potentially releasable product increment” be created by the end of the defined time-box.  I don’t see anything in this requirement that prevents a team from releasing sooner if both they and their customer can handle it.  I also find this supposed limitation to be a bit hilarious.  I mean, it wasn’t it but a few years ago that many organizations were struggling with delivering software more than one time a year!

User Stories

Is this in the Scrum Guide?

Daily Scrum

These days it’s become quite chic to state that instead of focusing on the individuals doing the work, we should focus on the work itself.  In other words, focus on the baton, not the runner.  The criticism of the Daily Scrum then is that every day, it’s the same (paraphrased) three questions that are asked:

  1. What did I do yesterday?
  2. What do I intend to do today?
  3. What impediments do I possibly have?

Unfortunately, these three questions (while represented in the Scrum Guide) are removed from the larger context for which they are a part of. Here are the first two lines of this section in the Scrum Guide:

The Daily Scrum is a 15-minute time-boxed event for the Development Team to synchronize activities and create a plan for the next 24 hours. This is done by inspecting the work since the last Daily Scrum and forecasting the work that could be done before the next one.

In fact, if you are interested, take the time to read that section (and the entire Guide) on your own.  Tell me where it requires you to “stand up”!

These are a few examples of things I often read people say “Scrum made them do…”  So is this a post to convince you to use Scrum?  Nope.  First of all, I don’t believe it’s always a fit for the type of work a development team might be doing.  Secondly, context matters and depending on your context (of which I have no idea of), something else might be better. However, I will challenge you to read for yourself what the rules of Scrum are so you can separate those rules from the traditions of men and make informed decisions.  Study to show thyself approved.

When I have these conversations in social settings, its suggested that the Scrum Guide has changed over the years.  When did change become a bad thing?  What happened to inspect and adapt?  Show me a method or framework that doesn’t evolve and I’ll show you a dead method or a dead framework.  The real problem is that many (maybe even most) Scrum Masters that I interact with don’t evolve beyond what they may have learned in their 2-day CSM course 7 years ago.  Ask them the last time they actually looked at the Scrum Guide or how many Scrum books they have read. The answer is often quite disturbing and disappointing.  (By the way this point extends beyond Scrum and into Agile (as an approach to software delivery).  The cargo-cult behavior of people who promote “inspect and adapt” can be quite disappointing).  Don’t even get me started on managers who try to impose Scrum (or any other Agile approach for that matter) in their organizations without having a clue.

Scrum is a framework that your team can leverage (if it’s a fit) to develop and deliver products in an Agile manner. It’s not perfect because nothing really is. There is no silver bullet and that includes your new approach as well.

Advertisements

Respect, Show Some More

I’ve recently spent a lot of time thinking about the notion of respect and its importance in social settings.

How would our interactions be different if respect was present when we engaged?  For example, if we intended to respect all the participants in a meeting, would we still dominate the meeting with our own opinions or would we share the floor with others?  What if a team member wasn’t performing at a high-level?   Would we take the time to try and understand what was getting in their way?

Because I’m actively involved in Twitter dialogue, I’m often saddened by conversations that become “insult parties” when people cannot agree.  As I recently tweeted:

Respecting each other doesn’t mean we have to agree on everything and anything.  In fact, that would probably be unhealthy.  For example, there are a few people in my Twitter circles who have suggested that we redefine Agile or move beyond it to something more “modern”.  I disagree with some of these thoughts (and that’s substance for a subsequent post) and yet I still respect them and respect the fact that they have that view even though I don’t agree with their opinion.

Respect (in my humble opinion) is even more critical when an individual is involved in cultural change (change management) initiatives.  As an Ibo boy growing up in a Yoruba community, I learned at an early age that taking the time to understand the differences in the cultures was an important form of showing respect.  If I wanted to be able to influence, I needed to respect (even if I didn’t agree). Later on in life, I was introduced to the famous Stephen Covey maxim:

Seek first to understand, then to be understood.

(What should we do when we’ve totally lost respect for an individual or group of individuals?  I’m curious to get your thoughts.)

Being respectful of others can be especially challenging in certain circumstances. Let’s keep trying.