7 Sins in Scrum
Practices even experienced teams should avoid
4 February 2016
Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.
Most of us in the software development profession are excited by the words "Agile" and "Scrum," and in one way or another you may have started following Scrum, either by self-initiative or per management directives.
In this article I want to point out some of the mistakes or misconceptions around Scrum that must be avoided, those I like to term "sins" in Scrum.
So, you may have just started following Scrum after working on multiple software development projects using Waterfall. Or you have already been following Scrum for the past couple of years, but you have adjusted its processes acoording to your organization's culture. In both the cases, you are bound to commit these sins. Yes, Scrum is a process that gives you flexibility, but at the same time remember: "Scrum is easy to learn but difficult to master." There is a high chance you carry the burden of past knowledge and practices.
Here are what I deem the 7 Sins in Scrum:
1. Converting your work hours into user story points
You have moved to Scrum, but you still first derive user story estimates in work hours or person days (PDs), then convert those to story points according to your past experience or organizational rule. Some persons consider one hour of work to be one story point, while others may consider one day of work equivalent to one story point.
Remember, Scrum works on the empirical process-control model, and it has its own unit of measure -- "story point" -- that should not be considered as a unit of time.
2. Increasing your story points to show more work done
You may be working in a multiteam environment where more than one team works in Scrum, on different modules or sub-projects. There will be always competition and comparison among teams and individuals. Sometimes to show that more work has been done (maybe because of management presure), people tend to increase story points. As a result, the actual work done/deliverable remains the same, but sprint velocity increases -- which may bring you some applause, but the business does not gain anything from this.
3. Making the project manager your ScrumMaster
This particular mistake is mostly made by organizations that start Scrum for the first time. For some of us, a "ScrumMaster" (maybe because the title includes the word "Master"!) is a "boss" on a Scrum team, and thus the position obviously goes to project/delivery manager.
This is a huge misconception about Scrum. Remember, a ScrumMaster is neither a boss nor a manager but a "servant leader" who thrives by making Scrum teams self-organizing and independent. If your manager is a ScrumMaster without these personality traits, then the development team will be less inclined to give honest answers regarding story points, reviews, retrospectives, etc.. They will tend instead to give answers that will "please the boss."
4. Making the ScrumMaster your product owner
Your team's product owner is going away on vacation for two weeks, and you need to fill her post. The ScrumMaster comes to the rescue. Or, even worse, there is no separate product owner role on your team to begin with; the ScrumMaster takes both roles. These scenarios each defeat the purpose of following Scrum. Remember, Scrum defines these roles as exclusive. A product owner should be customer-facing and having insight into the business; her role is more outbound than inbound toward the team.
The product owner is somewhat over and above the internal working of the development team and may or may not work very closely with them, but a ScrumMaster deals with the development team on a daily basis and is deeply involved with them.
5. Not having daily stand-ups
Some of us consider daily stand-up meetings or daily status meetings to be a waste of time and a burden. Some consider that the Agile project tools always show us up-to-date status, so why do we need a daily meeting? Some bring in the "ego" issue and feel that they are reporting to others who may be their juniors in experience.
Remember, a daily status meeting in Scrum is about proactive information sharing with everyone, and no one is "reporting" to anyone. It also brings an openness to the work and cultivates a feeling of shared responsibility among team members.
6. Extending your sprint beyond the deadline
You committed, but you cannot complete all your commitments. Maybe the technical curve was too steep for one of the stories, something you could not see up front; maybe one of your key developers fell sick and there was no one who could cover effectively. Cases can be many where you find yourselves streched and unable to meet work targets. So you'd like to extend your sprint by a day or two to complete what remains.
If you are following this practice, then know that it is most undesirable in Scrum. Scrum mandates timeboxed sprints, meaning their duration is fixed and a given sprint must end when its timebox expires, not when you accomplish all your tasks.
7. Not conducting retrospectives
The retrospective is another event in Scrum many think is avoidable, and others consider it a mere formality. But skipping retrospectives after each Sprint is a bad practice. Not only are you, as a team, missing a lot of important feedback from each other but you are also losing any chance of starting your next sprint right. Retrospective meetings provide insights into the positives of the last sprint that should be continued in the next, and they also highlight avoidable needs-improvement aspects that the team should take care in the next sprint.
Current rating: 4.5 (10 ratings)
The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.