7 Reasons Why Scrum Fails
Quite often software development projects are set up to execute work using agile methodology, like Scrum, but not setting things up in the right fashion often leads to chaos.
Although there is ample information on Scrum (and it’s not exactly rocket science), there are cases where projects have been paralyzed. This article discusses common reasons for such failures and how to avoid them.
To find out if this article is worth the read, answer the following questions. If your score is less than 50, then read on, even if your Scrum projects are running successfully.
Scoring method: You get 10 points for each correct response, zero for others. The answer key is given at the end of the table – no cheating, please.
1. Why did you start following Scrum?
A.Someone (e.g., a customer, boss or consultant) asked us to.
B.We evaluated the concept and found it useful.
C.We heard it delivers better results.
D.Our earlier methodology wasn’t working.
2. What is the source of your knowledge on Scrum?
A. Employees who have had Scrum training.
B. Internet, blogs or books.
C. Seminars and conferences.
D. A consultant who tells us what to do.
3. What are your software engineering practices at the workplace?
A. I’m not sure.
B. We assume that projects follow suitable engineering practices.
C. There are issues; we’re working on them.
D. They are well-defined, rigorously implemented and periodically reviewed.
4. What are your project goals?
A. Goals differ for each project.
B. Goals are generally known to project managers and executives.
C. Goals are clearly stated and communicated to the project team.
D. The goal is to quickly deliver working software.
5. How do the projects use software engineering tools?
A. For key SDLC activities, which are automated.
B. For bug tracking and configuration management.
C. For multiple activities.
D. I’m not sure.
Answer key: 1) B. 2) A. 3) D. 4) C. 5) A.
If you had a less than perfect score, here are the top seven reasons a Scrum methodology may not be delivering as expected.
1.Misconceptions about Agile
The concept of being agile is very alluring. But the term “agile” is often misinterpreted, and many software development hygiene factors are at risk. One has to understand the principles behind agile methodologies, which are well-documented and known as the Agile Manifesto. If project teams are making agile excuses for not doing something essential, such as software design, then it’s due to a lack of knowledge. There are multiple flavors of agile methodologies, and Scrum is the most popular. Proper training is essential at the beginning of a roll out, in order to clarify any misconceptions and provide essential knowledge of best practices.
2.Doing it Because Everyone Else is Doing It
You may feel pressured to adopt agile so your company doesn’t miss the proverbial bus. But is it really needed? Did you evaluate what makes it successful? What good development practices are lacking from your current methodology? Following Scrum without fully understanding it or without well-established expectations just doesn’t work. There are pros and cons to every methodology, and each one of them claims to improve productivity, timeliness and business value. One has to evaluate the elements that contribute to such improvements and see if they are really missing in the existing methodology.
3. Unrealistic Expectations
There are many advocates of Scrum who have already seen its benefits, but we don’t know why their earlier methodologies failed, causing them to adopt Scrum in the first place. What were their expectations when they moved to Scrum? To what extent are those needs being fulfilled? Scrum is designed to solve some – but not all – of the problems posed by conventional methods of software development. So, before switching to Scrum, figure out what your project challenges are and why the existing methodology didn’t solve them. Next, evaluate how Scrum can offer a better solution and why. Your judicious decision will set a precedent for Scrum adoption across the organization.
Problems, like volatility of requirements, may not simply disappear by adopting Scrum. All the stakeholders need to understand how evolving requirements are handled in Scrum and must commit to product and sprint backlog philosophy.
4.Lack of Software Engineering Discipline
A great deal has been stated and debated about the benefits of disciplined software engineering. Watts Humphrey wrote about it in layman’s terms in his popular column, “Watts New?,” on Carnegie Mellon’s Software Engineering Institute website. Practitioners need to realize that agile is not “undisciplined,” focusing merely on “working software” and compromising hygiene activities, like code quality. One has to keep in mind that “working software” can’t work successfully unless care is taken in all the stages of the development lifecycle. Secondly, there isn’t a special practice or shortcut that’s introduced by agile that allows developers to bypass hygiene activities without compromising the quality.
One of the founding principles of agile is collaboration between the team and the customer. This characteristic of agile attempts to resolve ambiguous communication. Frequent interaction among team members ensures knowledge sharing and clarity of expectations. The meetings are shorter and timeboxed, to minimize unproductive work hours. Formal communication protocols are abandoned. The customer is equally involved in the project, in order to promptly resolve queries and provide feedback on delivered software. If such collaboration is missing in the project or if the team can’t lose its bureaucratic culture, then agility will certainly be lost.
6.Missing the Right Infrastructure
Agile proposes that developers and testers should focus their energies on doing their core jobs better: writing code and conducting tests, respectively. It’s a simple productivity principle; however, it mandates that certain engineering activities, which aren’t dependent on human intelligence, are automated. Such automation has to go beyond just planning and tracking of sprints. For example, can some pseudocode be generated based on the UML of a user story? Can an automatic check detect coding error on check in? Can the build be created and tested frequently to ensure code stability? Can team progress be tracked in real time and, alerts raised when tasks are missed?
Scrum also promotes lean practices, such as time boxing, stand-up meeting and limiting non-core work. Identifying the right infrastructure is not an easy task. It involves many aspects such as choice of tools, the tools’ integration capabilities and expected ROI. A platform that supports Scrum evolves over time and needs to be integrated with long-term business goals.
7.Retrospection as Ritual
Nothing is perfect, and striving toward that goal requires a conscientious drive to systematically eliminate causes of imperfection. Retrospection is one such Scrum ceremony that encourages the team to do better in forthcoming sprints. But retrospection done merely as a “tick mark” activity will not reveal the impediments and their real causes. The team needs to be asked to plan and allocate bandwidth for making improvements between sprints. Often teams run the risk of forgetting to fix issues due to aggressive timelines and lack of management commitment. This issue can be addressed effectively if “improvement” is also treated as a deliverable.
By paying attention to these seven common causes of Scrum failure, software development teams can evaluate if Scrum is the right approach for them and avoid the hurdles that can turn agile into something unwieldy.
Image used with permission from Thinkstock.