Every now and then some one talks about or highlights a practice which has nothing to do with Scrum. Yet, due to widespread usage of the practice, people think that the specific practice is part of Scrum and should be followed to do Scrum in the right way. Sometimes, the Scrum Masters for the lack of knowledge enforce such practices and then feel the resistance.
I am not saying that every Scrum Team should know each and every right or wrong practice. That’s not how empiricism works. When I started as a Scrum Master back in 2010, I had my set of practices and I evolved. I expect Scrum Masters and Scrum Teams to have that journey. What I am unable to comprehend is the same practices of 2010 becoming anti-patterns for Scrum Teams in 2025.
Here is a rundown of some common wrong practices associated with Scrum and their ripple effects.
The 3 questions at Daily Scrum
The most common wrong practice is the 3 question template for Daily Scrum. At times, people don’t even call Daily Scrum a Daily Scrum, it is known as Daily Standup where the three questions need to be answered -
- What did I do yesterday?
- What will I work on today?
- Are there any challenges/blockers?/
When this happens, the Daily Scrum loses its purpose and gets converted to a status update meeting.
Impact:
- Loss of focus: As I mentioned, Scrum Teams lose focus on the purpose which is to figure out a day plan to achieve the Sprint goal and convert the event into a status update meeting. Sometimes it transcends into a problem solving meeting.
- Siloed Vision: Every individual developer is focused only on what they are doing or what they will do. There is no shared understanding about how to achieve the customer goals.
- Lack of Commitment: Since team members are having a siloed vision of work, there is no commitment from the team to achieve goals. The Developers are often focused on getting their individual work done but mostly disengaged or unaware of what the team members are doing.
- No Collective Ownership: When the commitment is missing, it leads to another challenge and that is ownership to get work done. At the time of Daily Scrum, someone was giving a status update and it was unrelated to my work, so I don't pay attention. And since I didn’t pay attention, I don’t really bother on who is working on what and if anything will be completed. As long as I am able to finish my task, I can always point fingers at someone else.
Sprint Goal that is also the Scope of Work
Most teams that I start working with do not have a Sprint Goal. A few teams that have a sprint goal, their sprint goal often looks like -
- Complete the feature abc by end of sprint.
- Our goal for this sprint is to generate a xyz report, update all dashboard and complete unit testing of feature rbc.
- Move the datasets from MSSQL to MySQL
I believe some of my readers might have encountered similar instances. Now these are not really goals. These are features to be completed, the scope to be implemented. But why do many teams end up doing this?
Well, for most teams having a Sprint Goal is merely a tick on the check box list that is handed over to them as a practice set. And when teams fall for the practice while missing out the reasoning, this is what they get.
Impact:
- No clarity of work: Scrum Teams have no specific objective to work towards. All people keep working in their silos.
- I over We: Since there is no shared goal, team members focus mostly on their own tasks and do not have a lot of focus on collaboration or team work.
- No scope for scope negotiation: The purpose of having a Sprint Goal is to have an ability to negotiate over the scope in order to achieve the goal. If Sprint Goal and Sprint Scope are the same then the team loses the ability to course correct to achieve the Sprint Goal.
- Sprint Failure: Emergence of another wrong practice. Scrum Teams start calling out Sprint Failure if they are unable to deliver all the work planned or described in the Sprint Goal.
The Definition of Ready
Definition of Ready is another widely adopted practice that leads to many challenges. In Scrum, there is no such checklist as a Definition of Ready. Scrum promotes a “Ready” state that is acquired through continuous product backlog refinement discussions. The main purpose of having a Product Backlog Refinement is to create a shared understanding about the work to be done by adding details such as description, estimates and size to the requirements.
When a Definition of Ready is established, Developers tend to rely more on the checklist and less on communication and collaboration.
Impact:
- Phase Gate: Scrum Teams establish a phase gate that hinders customer collaboration. They try to create a checklist which needs to be met even before the Developers would want to look at any requirement.
- Lack of Shared Understanding: When a rigid DoR is established, the interactions between people are reduced and assumptions are made about the requirements. Thus there is no clarity among people about what is needed and what should be done.
- A false sense of clarity: Often, having a Definition of Ready gives the Scrum Team a false sense of clarity. When the Scrum Team hits the roadblocks or dependencies during their actual work, all their plans are shattered and the forecasts go for a toss; resulting in delayed value delivery or none at all.
The obsession of a User Story
Another common non-scrum practice that takes over Scrum teams is User Stories. Every requirement needs to be written as a User Story. This obsession with User Stories leads to requirements in the Product Backlog which look very similar to:
As a Database
I want to execute a trigger
So that an SQL report is ready
A user story needs to be created if there is an user interaction happening with the system, not always. The aforementioned example shows how over the last 20 years teams are again falling back to processes and tools without improving individuals and interactions.
Impact:
- Mismatch in expectations: Technical requirements often do not fit the structure of a User Story, yet when described as User Stories either lose the context, lose the details or create artificial constraints.
- Lack of Clarity: When trying to fit requirements in the User Story format a lot of details can be left out due to the oversimplification of the requirement. This impacts the overall clarity of the requirement and leads to reduced understanding of the requirements.
- The Story Mania: Often teams become obsessed with the format instead of focusing on the value of the practice. This leads to rigid processes and creating requirements that do not provide right understanding nor the desired guidance to create a valuable increment.
The Proxy Product Owner or POP
The next common practice which I have observed in multiple off-shore teams is the Proxy Product Owner or the POP. This person is more of a coordinator or a bridge between the real Product Owner aka the client and the Delivery Team aka the developers at off-shore. The Proxy has no say whatsoever on the Product Decisions but is a mere relay of the Product Owner. At times this person may not even have enough knowledge or domain expertise to address day to day questions of the developers.
Impact:
- Delayed Decision Making: Since the Proxy is not really a Product Owner, this person can’t really make any decisions. Every decision needs to be run through the actual Product Owner and that lengthens the chain-of-command and delays feedback.
- Lack of Transparency: The proxy PO is often an order taker. They do not have authority but since they act as the bridge between the client and the developers they often add their assumptions, experiences and biases while relaying the information to and for leading to lack of transparency. This might even lead to misaligned priorities because of the difference of understanding what was conveyed and what was understood.
- Wasted Time / Increased Rework: The lack of transparency then introduces another challenge. When the Developers develop something as per the information relayed to them via the proxy and it does not meet the expectations of the “real” Product Owner, it requires to be redone resulting in wasted effort and time.
- Impact on Value Delivery: The idea of running a Sprint is to get to a DONE Increment so that value can be created for the end user. However, with lack of transparency, miscommunication, wasted time and effort the value delivery is often delayed. And even when delivered often there is no guarantee of Value being created.
The Sprint Zero
And one last I will like to highlight which to my knowledge is the most widespread incorrect practice associated with Scrum and that is the Sprint Zero. When the question is asked - what do you do in Sprint Zero? The answer often is - set up the environment; layout the groundwork for architecture and design, establish all the requirements, do the necessary analysis and so on.
Follow up with the question - when is the increment created? Or how long is this Sprint Zero? No surprises. No increment is created during Sprint 0. It can be anywhere between a month to a quarter.
And that is not a Sprint. Not in the Scrum context.
The only reason to execute a Sprint is to create a valuable, useful increment. If it is not created, it is not a Sprint, it is not Scrum.
Impact:
- ScrumFall: The Sprint Zero is reminiscent of the traditional world. It creates a phase gated approach and impacts agility. It might also lead to additional phases like the dev sprint, test sprint and release sprint. Some of us have also come across what is known as the hardening or integration sprint. In short, Sprint Zero is very much a waterfall relabelled with Scrum terms.
- Unrealistic: The Sprint 0 builds upon the unrealistic idea that everything about a new product could be established beforehand and a day to day plan can be charted out. It also hinges on the idea that requirements can be frozen, based on which the architecture or design can be defined. Has that notion ever been true? With my learning and experiences I can say it was not true in 2001, it was not true in 1995, it wasn’t true in 1986 or 1970 and it is definitely not true in 2025.
- No Empiricism: When a Product Development approach starts with concepts like Sprint 0, it leaves no room for Inspection and Adaptation. No focus on emergent architecture or design, no space for responding to change and no creativity or innovation either. Scrum Teams that fall for the Sprint 0 they start on a wrong foot and have no scope for empiricism to work for them. Their scope, timelines and everything else is already fixed, all they are doing is the mechanical scrum to tick some checkboxes.
Conclusion:
One of the key principles on manifesto for agile software development is -
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
However, it seems the principle is forgotten. Teams are not reflecting. Everyone is just copy pasting practices, tools and methods without focusing on whether they are effective or not.
These practices are leading to ineffective Scrum and wasted effort. In order to take advantage of Scrum, encourage the Scrum teams and the Scrum Masters to be wary of these pitfalls and challenge them as needed to make the Scrum Teams effective.
P.S:
If you are interested to uncover more such anti-patterns and want to enable your scrum teams to be more effective then connect with me via any social media or head to our website www.agilemania.com to explore our offerings.