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.