This article assumes you know the basics of Scrum/Agile methodology and you are already practicing Scrum for your software development project. If not, then I suggest you to read the basics of Scrum first, then read this article.
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 "pitfalls" in Scrum.
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 according to your organization's culture. In both the cases, you are bound to encounter in these pitfalls. 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 seven pitfalls in Scrum:
Converting your work hours directly 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" which should not be considered as a unit of time.
Increasing your story points to show more has been 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 pressure), people tend to increase their user story’s 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.
Making the project manager your Scrum Master
This particular mistake is mostly made by organizations that start Scrum for the first time. For some of us, a "Scrum Master" (maybe because the title includes the word "Master"!) is a "boss" of a Scrum team, and thus the position obviously goes to project/delivery manager.
This is a huge misconception about Scrum. Remember, a Scrum Master 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 Scrum Master 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".
Making the Scrum Master your product owner
Your team's product owner is going away on vacation for two months, and you need to fill her post. The Scrum Master comes to the rescue. Even worse, there is no separate product owner role in your team to begin with; the Scrum Master plays both roles. These scenarios each defeat the purpose of practicing Scrum. Remember, Scrum defines all roles as exclusive. A product owner should be customer-facing and having insight into the business; her role is more outbound than inbound towards 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 Scrum Master deals with the development team on a daily basis and is deeply involved with them.
Not having standup meetings on daily basis
Some of us consider daily standup meetings or daily status meetings to be a waste of time and a burden. Some consider that the Agile project tools always show 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.
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. It also brings a feeling of “
responsibility” to development team members as they report daily what work they have done in past one day.
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 stretched and unable to meet work targets. Hence, you'd like to extend your sprint by a day or two so that your team can finish what remains yet to be done.
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 it’s timebox expires, not when you accomplish all your tasks.
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, are 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.
I hope you have noted these pitfalls and you will avoid those in your actual practice.
Disclaimer
This article was originally published by me on ScrumAlliance.org membership website here.