Good recipes to fail in Scrum

Scrum framework is just like cooking good food, though it all come by experience but following the best practices will optimize the result and ultimately a satisfied customer. Recently I got a chance to observe few projects which said that they are following Scrum and then went on to fail and close within few months. I will say it was one of the very good experiences for the team, and a good paradigm of the adage in agile world that “Early failures are good”.

In this article I have noted down all those recipes which I observed, which can lead to a bad dish or to say dissatisfied customer, a failed project etc. I am not suggesting direct solutions instead just identifying what were the shortcomings which paved the way for a project to fail by not properly following or adopting Scrum framework.

Recipe # 1: The very first recipe to fail was that the team was not very well aware of the Scrum or Agile framework. Neither the team was initially made aware of the basic know-how of what all scrum roles, events and artifacts nor were any formal trainings provided to the team. Adding to that there was no planned budget for any of the trainings to be organized for the team.

Recipe # 2: Product Owner who is one of the important pillars of the Scrum Team, was absent for the team. There was temporary arrangement done by appointing a single person, who was the product owner of some other team to act as the product owner for few other teams. No thought was given whether the appointed PO has the technical or domain or required PO skills. Eventually the team struggled as the PO was not able to answer the queries put up by the development team.

Recipe # 3: One important observation related to PO was that he was changing the scope of the user stories in between the Sprint. Not only this the acceptance criteria for the stories were also changed mid-way of the Sprint. It seemed there was a lack of ownership by the development team and also lack of clarity about the ownership of the product backlog by the PO. It happened to be more of a command and execute approach been followed by the PO and he want to dictate the terms on what and how much the development team should work. I can say here that this situation occurred as there was lack of clarity by the PO about its role and responsibilities.

Recipe # 4: The development team was not technically competent enough (there was not a good mixture of experienced team members with good technical and domain knowledge) in order to address the technical issues and thus the team lacked cross-functionality.

Recipe # 5: Development team spent a lot of time in discussing on the problems thus eating up a lot of their time during the sprint execution. Although they could have instead included one user story to research and come up with a solution.

Recipe # 6: Product owner dictated which stories to be taken up in a Sprint. There was no negotiation between the development team and the Product Owner regarding the scope of the stories. There was no buy-in by the team on which user stories they could complete within the Sprint. Ultimately the team lacked confidence and clarity on how to work on the stories.

Recipe # 7: Communication happening in silos: product owner was not communicating to the team instead to only few members within the team. Also product owner considered SM as a technical Lead and was communicating to the Scrum Master seeking technical clarifications from him.

Recipe # 8: The development team was not having any definition of done (DoD). Neither the development team cared to write a definition of done nor the Scrum Master helped them in knowing what is DoD resulting in non-acceptance of the user stories by the Product Owner.

Recipe # 9: Sprint retrospectives were either not conducted or happening with only product owner providing its point of view, either few development team members participate in the Sprint retrospective or the participating members do not speak or share their observations.

Recipe # 10: Development team had members working in silos. They lack trust and confidence to speak up either with the product owner or with the Scrum Master for any of the impediments they face. The team just following few scrum practices for the sake. There was as disbelief by the team members in any of the scrum practices.

The most vital observation which made this recipe good to fail is that the management was less supportive of the Agile Methodologies and lacked knowledge about the Scrum framework. They still have that command and control approach which suggests that the teams should be kept well within the reins which eventually hinders the development teams to become self-organized and cross-functional. Not only this the management or the leadership team lacked faith in Agile and were merely pushing the teams to adopt agile for the sake of their customers. There was no gravity and commitment seen by the leaders to be agile instead the focus was to just do agile.

I assume such situations many of us would have seen or are observing which are happening across an organization and it requires a change driven from the top by amending the organizations culture and involving everyone in an organization.