Blame Scrum

So, hopefully you read my post (click here) from yesterday.  I have found, over the years, that Mike’s viewpoints on Scrum are valuable and practical.  Again, if you haven’t signed up for his email/blog, you should.

On to my commentary:  I have to admit that I often used the By The Book (BTB) approach when I am asked to implement Scrum.  I like the point of taking the personal aspects out of the conversation, which makes it easier to focus on the real issue.  Using it as a shield allows for the conversation to continue without interrupting the current work.

As I have stated in the past, I am very much a believer in the ShuHaRi approach to learning.  I have spent countless hours as a kid practicing the basics at night (trumpet, basketball) to the chagrin of my parents’ neighbors.  I am not Winston Marsalias or Larry Bird, so I never became a master, but it wasn’t for lack of trying.

So, why do organizations think that they can send everybody to a class, do some handwaving, and think they can implement a new process or framework.

Often, when implementing Scrum, the tendency in organizations is to make exceptions without understanding the intent of the framework.  The exceptions often manifest themselves in that  “This request is special.”  Sometimes, it even takes the form of “You don’t understand.  Our company is special, and that isn’t the way we do it here.”

Yea, right.  Special, huh?

If you dig in, you will find that 99 times out of 100, FUD (Fear, Uncertainty, and Doubt) are at the root of the request.  Often the most resistant to change are those that are in the business of implementing change.  As software professionals, we develop products and processes that, upon completion, introduce change, yet we don’t want change introduced in our world.

An Example

Let’s consider an example:  A Scrum team believes it is wasting time with too many meetings and the team wants to skip the Sprint Review and let the Product Owner demonstrate the work to the stakeholders.  While that might be expedient for the team, the Sprint Review is an opportunity for stakeholders and the Scrum team (including the Product Owner, the Scrum Master, and the Team) to  inspect the work (Product Increment), and discuss changes, new ideas, and the direction for future sprints.  In response to the request, the Scrum Master should blame it on the framework, and work with the team to understand that the benefits of the Sprint Review as an opportunity for feedback in the form of inspect-adapt for the Scrum Team and Product.

Being an empirical framework, Scrum encourages us to adapt based on learning and experiences.  However Scrum teams, early in their adoption of the Scrum framework aren’t experienced enough with the framework to understand the impact of those kinds of decisions.  Using the Scrum process as a shield to temporarily fend off these diversions can greatly help.

Thanks for coming in today.

Chris