Tuesday, November 20, 2012

6 Common Wrong Ways to do Scrum

There's a lot of differences in how people are doing Scrum. Some (not many) differences are with the core framework, and more are outside of it. I get very concerned with any changes with the core framework.

If a company decides they need:
  •  a role of Technical Product Owner or Proxy Product Owner, or 
  •  a five week sprint, or 
  •  a services team creating only web services for other teams, or 
  •  a design team doing UX work, or 
  •  an architect team doing look-ahead work, 
  •  or are writing stories that span two sprints because the testing process alone takes over a week.
I want to talk with them about why. Although they are breaking part of the core framework, to me it's less about breaking the rules and more about violating the principles underneath why Scrum works, and to help them see and understand that. It's more important that they understand why Scrum works rather than are they or are they not following the rules.

For example, a team has a Technical Product Owner because neither the Product Owner nor team members understand the system well enough to make educated decisions. Do they want the team members to have that knowledge? They usually say yes. Then that is the goal (and the issue), and not the Technical Product Owner role. Ask why the work-around is there, and then see if that root cause shouldn't really be the focus and problem to solve.

Growing up, I was trained to turn the wheels when parking on a hill. I didn't understand the importance of that until one day I drove up the hill to school and saw what used to be Karen's VW bug. She had parked it at the top and but the parking brake had slipped, and the car had rolled down the hill, gained momentum and flipped several times. Had the tires been turned, the car would have just bumped in the curb and then stopped. Rules and principles can be disregarded if there's not an understanding and respect of why they're there.

For variations I've seen outside the Scrum framework, I'm interested but not always concerned. For example:
  •  the user story format
  •  how non-functional requirements are handled
  •  the estimation point sequence
  •  whether estimation is done using planning poker or team estimation
  •  whether the stories are broken down into tasks or not
  •  how project work is approved
  •  the role of the Project Manager, managers or architects

These topics become conversations about what works best for the team, and that's who I'm primarily listening to. If it works for them, they'll do better work, and that's a win for the business.

1 comment:

Andrew Rusling said...

I agree with the items that mention as causes for concern.

When teams want to break the rules I like to dig into the situation to understand what is driving their decision. Similarly to what you have experienced, I often see that teams who are new to Scrum have misunderstood the principles. In this situation some guidance is needed to bring them back on track.

However I am most excited when I find out that their reasoning is sound behind their decision to break the rules is sound. This tells me that the agile principles and agile way of thinking has sunk in. It gives me hope that they will continue to be agile long after I have gone.

My Blog: Journey To Better