I’ve had the opportunity to talk to a few local organizations on Scrum, and also had attended some formal Scrum courses (scrum.org) to sort of align back with the mothership on what Scrum is, or should be.

My conclusion is that there is a lot of confusion around Scrum practices which leads unsurprisingly to the questioning of its benefits and attempts to modify it.

An overarching problem is that Scrum simply isn’t being executed properly.

I have an analogy for this – being Canadian, hockey is where the thought pattern normally flows, but is applicable to any team sport. Hockey, like any sports, has a body of rules and referees execute those rules on the rink, field, or pitch.

Likewise, the rules of hockey do not tell you how to play hockey. They do not tell you how to execute a power play, or that you can pull the goalie for an extra attacker if you’re down a goal, or you should shoot high on a particular goalie because he goes down on the ice too soon, or that you should line up the players this way or that way to counter the lineup on the other side.

The richness of Scrum is in the proper execution by a team; the rules are mainly the guardrails along the side to make sure we’re playing all playing the same sport – hockey, not rugby, or football.

Yet we seem to persist with Scrum leaders that only seem to know how to referee, not coach. We need those coaches that can see the rules as its creators did. Scrum is both incredibly flexible because its rules don’t actually create boundaries as they appear to.

I’ll write further on this, but let me touch upon one concern at a time. Here are a few objections I’ve heard:

1. Our Lead Developers are swamped having to do the estimation work
2. Scrum doesn’t handle out-of-band requests like emergency bug fixes
3. We need longer than 2 weeks (or a month) to release something because our systems are complex and changes are required in many different places
4. We can’t realistically release an Increment into production every two weeks because our testers find bugs in the test environment and we have to fix them.
5. We have a continuous improvement or continuous development methodology and we like to deploy during a sprint. We can’t always wait until the end of the sprint.

Here are some potential answers:

1. A fundamental concept of Scrum is the cross-functional Team. The Team is the one tasked to help create estimates. Having a Lead role runs somewhat counter to this idea. At the very least, it takes some control away from the developer that may actually be doing the work (assuming it’s not the lead developer). And it’s definitely causing the lead developer a lot more work to take on this extra responsibility that could be shared among the team. I would suggest that the estimation work be done by the whole team at the appointed time (a backlog refinement meeting once every sprint.
2. No, Scrum doesn’t handle bug fixes, obviously, or any emergency situations that can throw an entire Sprint’s progress in jeopardy. Transparency with stakeholders as well as an organized process is what Scrum encourages, so that everybody knows what’s happening. A single point of contact through the Product Owner is very helpful in deciding if a bug is important enough to be fixed immediately, or if it can be put on the backlog for the next Sprint.
3. Scrum suggests no longer than 4 weeks for a sprint. Four weeks is really based on the fact that organizations work on a month-to-month basis for generating financial or other metrics. These are the metrics that help determine the value of our development efforts and are therefore crucial to be aligned with the outputs of these development efforts.
   A second answer that can be indicate the need for a philosophical shift in the development process is that you may need to look at delivering thin, vertical slices of functionality across all systems rather than dividing the efforts horizontally; i.e. a front-end team plus a back-end team working independently, but having deep dependencies.
   Vertical slices of functionality allow for more agile adaptation to change, as you should only be implementing as much as you need to deliver functionality, rather than building excessive in advance in hopes of utilizing it in future.
4. Scrum should encompass the entirety of the product development process – “tossing the product over the wall” and having gated tasks beyond the sprint, such as testing, hardening, deployment, security testing, and so on violate the idea of having a product Increment that is ready for production. It also gives a wrong impression of the state of the product – if there are bugs or remaining quality checks to pass, then it is most definitely not done. The fix to this is to create a more stringent definition of Done for the sprint that includes the quality criteria, the testing, and other tasks that were previously outside the sprint.
   This will potentially impact the perception of what is achieved in a sprint, but it is much more truthful and transparent to the entire development process as a whole.
5. Continuous Deployment is not forbidden by Scrum – the Sprint should be seen as a cadence or rhythm for ensuring the Scrum artifacts occur on a regular basis, rather than enforcing a fixed delivery window of the an all-mighty and encompassing Increment at the end. Each task could simply include in its Definition of Done a “deployed into production” checkbox.
   Continuous deployment is fantastic, and a great way to ensure value is delivered as soon as possible; why not deploy a feature the moment it is ready?

As you can see, it is sometimes the perception of what the rules mean that can be impediments to a great Scrum implementation. One needs to look deeper at the intention of Scrum, rather than the raw rules or literal interpretations of what each Scrum artifact implies.