Our focus the last few episodes have been on anti-patterns relegated to a specific role.  We take a step back in this episode and review scrum team anti-patterns.  These are mistakes we make on a whole that can derail our project and reduce velocity.  These can even drive a product into failure.

Deliver The Wrong Thing

There are many ways this anti-pattern can make an appearance.  The story may be too vague, requirements gathering is insufficient, or the dev team misses the point of a feature—all of this boils down to a communication problem.  Yes, we have once again come to a point where our problem and solution fall under the category of communication.  This time the root cause is a failure to perform our duties fully.  We have to be diligent in our work, and cutting corners can lead to this mistake.

Lack Of Urgency

Any good coach knows that part of their job is motivating the team.  There needs to be a sense of urgency or some objective that the team focuses on.  A sprint has this feature built into it in the form of the working software deliverable.  Unfortunately, we have this situation that is as much everyone’s failure as any of the scrum team anti-patterns.

The team sets the objective and story for every sprint.  When we decide (as a team) to skip a deliverable, we open up this can of worms.  A lack of a deliverable can remove urgency in a sprint.  It is like studying a topic where there will be no test.  We are allowed to flounder and progress to our level of comfort.  Most of us will not push ourselves when this occurs.

Pass The Buck

Another facet of the lack of urgency is this anti-pattern.  A sprint has a mechanism for pushing items to a future sprint via rollover or returning to the backlog.  This option can be over-used and cause us to feel like a task will be covered at some point with no need to address it.  This can be seen as a Scrum master problem.  However, the team often allows tasks to fester rather than force them to the forefront.

Variable Sprints

We have mentioned a need to compare sprints to each other.  This objective is difficult or impossible when we change critical factors of a sprint such as duration.  The team must do what they can to protect the resources and constraints for each sprint.  When this is done, it provides a better comparison of each sprint to measure our progress truly.

Learn More About Scrum

Challenge of The Week: Which of these do you see in your team?  How will you fix it?

Rob Broadhead

Rob is a founder of, and frequent contributor to, Develpreneur. This includes the Building Better Developers podcast. He is also a lifetime learner as a developer, designer, and manager of software solutions. Rob is the founder of RB Consulting and has managed to author a book about his family experiences and a few about becoming a better developer. In his free time, he stays busy raising five children (although they have grown into adults). When he has a chance to breathe, he is on the ice playing hockey to relax or working on his ballroom dance skills.

Leave a Reply