Scrum Tips

If What You are Doing Works, Does the Label Really Matter?

Recently I had a brief messenger chat with a former co-worker that they determined they were actually using Scrum-ban instead of Kanban.  The timing of this chat coincided when I seemed to be coming across a multitude of discussions about what is or is not in Scrum, what is or is not Kanban and so on.

My initial response was “is what you are doing working?“.  Her response was, “yes“.

My response, of course, then was “so why does it matter?”

I do understand the desire to have these processes defined but I’ve never much been a fan of labeling.  Being “Agile” isn’t about using Scrum, Kanban, Lean or any other tool/process, it’s about being dedicated to empirical processes that work within the context.  I also understand the dangers of  ”Agile” being tarnished by misused practices but by and large solving problems and rejecting the status quo are what really matters at the end of the day.

As an example, a few months ago a team member who was recently kicked off the team BY the team, decided it was worth his time to prove a point by finding a page in Ken Schwaber’s book that mentions it’s not a rule for the team to stand-up at the daily scrum.   My reply was pretty simple in the sense that I never said it was a rule.  I explained to the team why it’s a good idea to stand-up and the team decided they wanted to sit, so they now sit. (results of our daily ‘sitdown’ here).

Is sitting at the stand-up a Scrum smell?  Probably. I don’t care though.  The team gets more value out of sitting.

Before I knew what “Agile” was, common sense would dictate that if something isn’t working, find a better way of doing it by trying something new. I believe that’s much more valuable than worrying about what label you put on it.

Agile Just Don’t Go ’round Here

One of my favourite scenes from Tombstone is when Ike Clanton says to Wyatt Earp, “Listen, Mr. Kansas Law Dog. Law don’t go around here. Savvy?”  After Wyatt replies that he’s retired, Ike reiterates “Yeah, that’s good, Mr. Law Dog, ’cause law don’t go around here.

A common theme that has been emerging from the classes I’ve been delivering and conversations I’ve been having are along the lines of “wow, we need to change our culture” or “agile won’t work here because … <insert excuse>“  There seems to be a clear delineation between these 2 camps.

I blogged previously about the importance culture has with an Agile transformation and I make sure that I convey that to anyone I talk to that is new to Agile.

The first statement I usually use to combat this fear, uncertainty and doubt is the fact that there always must be a reason to transform to Agile.  Companies aren’t switching for the sake of being cool and hip, well if they are they have bigger problems, but instead they are switching because fundamentally, the way they are working is broken.

Transforming to Agile requires a deep organizational commitment and a fundamental shift in how companies operate and how departments and people interact with each other.

So underneath the skepticism and FUD, what’s the REAL problem?  What are people afraid of?  Here’s a brief summary of the top 3 excuses for why Agile don’t go ’round here:

1) We can’t have a SINGLE product owner, we need multi-level signoff and too many people are “the go to guy”

2) Agile won’t work here, everybody works on multiple projects at the same time.

3) Management tells us we HAVE TO launch with all these features on this date.

Hmm.  So what do we do?  Where’s the Agile checklist that allows us to fix these problems?  I’ve seen Scrum teams absolutely banging their heads against a wall trying to figure out why their fixed-date, fixed-scope projects either don’t make it or have terrible quality.  In this cas,e the ‘rapid de-scoping phase‘ happens in order to make the date but in that instance the damage is already done.  The teams inability to say no has rendered their yes useless, mis-trust ensues and the cycle repeats itself.

I’ve had this post brewing for a few weeks and decided to post it after our pilot team’s recent success and after reading Gil Broza’s great post entitled “so you think you’re Agile?

While our topics do differ, the underlying tone is the same.  Organizations needs to understand what being Agile is.  They need to look to the manifesto, not to the Nokia Scrum test or a checklist.  They need to un-learn what has been instilled through so many years of the command and control approach.

AYE helped me change my approach from saying “here’s what you’re doing wrong and here’s the right things to do” to “what are you concerned about?  what are your challenges?  how can the knowledge and tools I have solve your problems

Lately that approach is working much better and I find people who want help are more likely to accept help.

The Definition of READY

Serge Beaumont posted a great article on the The Definition of READY at Xebia Blog.  While the concept of being ‘ready’ for iteration planning is already in Scrum, I have found that it’s not something that gets a great deal of attention.  Product Owners are left to “get stories ready” without having a clear definition about what that means to the team.

I think the power of self-organizing teams have trained people to leave out the “how” until the team decides that in the planning session but as Serge points out “how” is a by-product of iteration planning and I would tend to agree.  Teams need to have some understanding or thoughts of implementation before they can commit to a batch of stories and a Definition of Ready is a great way to get there.

The problem I see with the Definition of Ready is that it can be quite complex depending on the type of story.  You may have stories that require UI changes, look and feel or legal changes that would make your Definition of Ready bigger than say stories that are geared towards updating an API or adding simple functionality.

Should you define the definition of ready for each story?  Should you have a base definition of ready and add/remove items as necessary?

Personally, I would move to having a Product Owner work in iteration sizes that are half the length of the team’s iteration to prepare stories with the definition of ready.

Monday, Week 1:

  1. Iteration 1.T (the teams iteration) starts

In the Teams iteration planning session the team commits to their work, does their detailed estimates and task breakout.

During this week the PO or Product Team is grooming the existing backlog, re-prioritizing stories based on output from the last demonstration and working with the customer, again, to groom the backlog.

Monday, Week 2:

  1. Iteration 1.PO starts: this is the PO or Product Team’s iteration to “get to ready” for the next set of prioritized user stories.  The PO meets with the team to define what ready for these stories mean.

Friday, Week 2:

  1. Demo session: PO “demos” the readiness checklist discussed in the 1.PO planning session
  2. Retrospective:  1.PO iteration retrospective that will allow the PO or Product Team to improve how they “get to ready”

Monday, Week 3:

  1. Iteration 2.T (the team’s next iteration) starts: The team defines and commits to the stories that were given the “ok on readiness” from the previous Friday.

The benefits of this approach is that all the “readiness” activities can (and should!) be timeboxed so there is an expectation that the team will need to participate in another short session.

It also helps get the PO and Product Team into a rhythm while also leveraging the power of retrospectives so they can improve on how they gather stories and get them ready.

I threw this post together rather quickly but it’s something I’ve had noodling in my brain for a while, would be very interested to hear others thoughts and experiences about how you get to ready.

Switch to our mobile site