If you are someone who has had limited or no success with Scrum and the title of this post forced you this way, well, I have met my first objective.

Last couple of years I have had an opportunity to connect with multiple teams that have been doing Scrum but have had very limited or no success with it. What I hear most frequently is “this does not work for us”. Further analyzing the data talking to these teams, some very specific reasons surfaced and I am listing them below:

1. Too much focus on Scrum “process” – The biggest reason why teams are unable to derive any benefits from Scrum is because they look at it strictly as a process. Scrum is a methodology but every single aspect of Scrum has very specific objectives. However; most teams are seen going through the motions without necessarily fully understanding the objectives and benefits of all Scrum artifacts and ceremonies.

2. Not doing Scrum right – Scrum is intended to be done in a specific way. Talking about the “Shu-ha-ri” approach to Scrum, the teams are initially expected to follow the rules of Scrum, however; teams start to make changes to it to often to suit their environments and projects which for obvious reasons reduces the effectiveness. Changing the frequency of ceremonies, micromanaging the team, forcing teams to deliver defined velocity and to dates instead of value etc.. are most common anti patterns that have been observed.

3. Fear of being exposed – Scrum is not designed to solve any problems, however; Scrum is designed to expose problems as early as possible with the belief that teams will be able to address them. Inability to produce incremental value for business, inability to measure business value, not having a well defined backlog, carrying work over from sprint to sprint, and many more of these data points expose teams ability to plan, execute and deviating their focus from the three pillars of Scrum (transparency, inspection and adaptation).

4. No slack time – There have been very specific areas where teams enjoyed huge slack periods due to the phased approach to software development. Teams would develop code and then sit back for defects to be identified or environments to be refreshed thus giving teams slack periods. In enforcing the need to deliver value continuously, Scrum and other agile methods have forced the team to be on their toes all the time. This obviously makes people uncomfortable and increases the risk of them getting exposed.

5. Resistance to change – Analyzing the previous points, it all boils down to the fact that the failure of Scrum can be attributed to the resistance to change. Companies, teams and individuals are not willing to change even if their current processes are not working. The possibility of getting exposed or the pressure to get out of their comfort zone brings the resistance to agile and Scrum.

The mindset

As you might have heard before, agile/scrum is not a process but a mindset and needs a completely fresh approach to how problems are identified and solutions are arrived.

I read an interesting analogy about Scrum and the impact of not doing right. Trying to make your grandmother’s recipe of Carrot cake, if you make your own decisions instead of following the exact recipe, you cannot expect your cake to taste like your grandmother’s. In the same way, Scrum needs to be done as prescribed before teams can start experimenting with it.

Having spoken to hundreds of team and maybe thousands of individuals, the observation is that companies are not doing Scrum. At best they were doing waterfall with iterations. The idea of continuous improvement does not seem to exist and this is a serious problem.

I love how Philip Grove, CEO at Confluex puts it:

• Scrum is like whitewater rafting. The rafting team members each have a job, they know how to perform it, and they know the team’s short term goals very well – “get beyond the first rapids.” They vaguely understand the approximate long term goal – “Get to the end of the river.” And, they know they have to work together, and help each other succeed. Finally, they know that everything else is pretty much going to change. The rocks aren’t always in the same plae, the rapids are moving faster, a log is floating alongside the boat. The team has to pull their strengths to get through, and make collective changes along the way.
• Waterfall project teams are military ships with a crew, a captain, a detailed set of orders, and an admiral relaying changes from command.
• Scrummerfall is taking that rafting team, with a captain, the orders, and the admiral relaying changes. This is a recipe for failure.

Post Script

Companies need to create a culture where failures are not necessarily looked as a sin but what you learn from your failures if of paramount importance. This will help create an environment where the three pillars of Scrum (transparency, inspection and adaptation) will help create a very strong foundation for continuous success.