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.
Be the first to comment on this post using the section below.