Recipes to Fail in Scrum
Following this list of anti-pattern Scrum recipes will ensure that your developement team and their product fails in record time.
Join the DZone community and get the full member experience.Join For Free
Scrum frameworks are just like cooking good food: though it all comes by experience, following the best practices will optimize the result and ultimately result in a satisfied customer. Recently I got a chance to observe a 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 good experience for the team, and a good paradigm of the adage in the agile world that “early failures are good.”
In this article, I have noted all those recipes which I observed, which can lead to a bad dish or to a dissatisfied customer, a failed project, etc. I am not suggesting direct solutions, instead just identifying what the shortcomings were which paved the way for a project to fail by not properly following or adopting Scrum framework.
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 trainings to be organized for the team.
The Product Owner, who is one of the most important pillars of the Scrum Team, was absent for the team. There was a temporary arrangement done by appointing a single person, who was the Product Owner of some other team, to act as the Product Owner for a few other teams. No thought was given as to whether the appointed PO had 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.
One important observation related to PO was that he was changing the scope of the user stories in between Sprints. Not only this, but 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 being followed by the PO and he wanted to dictate the terms of 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
The development team spends a lot of time in discussing 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: the Product Owner was not communicating to the team, but instead to only a few members of the team. The PO also considered SM as a technical Lead and was communicating to the Scrum Master seeking technical clarifications from him.
The development team had no definition of done (DoD). Either the development team didn't care to write a definition of done, or the Scrum Master didn't help them in knowing what is DoD, resulting in non-acceptance of the user stories by the Product Owner.
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.
The 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 of it, but with 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 the 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.
Opinions expressed by DZone contributors are their own.