Don't fall victim to these 5 Scrum anti-patterns

1. Backsliding to what's familiar

This is the big Scrum anti-pattern and the one that is arguably the root cause of most others.

Backsliding is the art of reverting into a comfort zone, usually a Waterfall methodology. The anti-pattern tends to occur when flustered Scrum teams come down to the wire with lots of incomplete stories and little time to get them marked done. For example, the team rationalizes the backslide and say they're still doing Scrum by holding a daily stand-up even though the confab is masquerading as a defect triage and status meeting.

Project managers backslide when they ask the age-old question, "What percent complete is it?" They also revert to Waterfall by trying to find out who's at fault for certain outstanding tasks. This relapse often happens under the guise of detecting obstacles and letting self-organizing teams address workarounds.

Backsliding is also when teams suddenly find themselves meeting almost daily in midsprint to define, redefine and document requirements because the original stories were too vague. Likewise, QA testers find missed requirements or require additional regression testing. All this chaos is done under the pretense of iteration, but it's happening because teams are reverting to the processes they know and once did well.

Yes, there is a whole generation of staff that comes into the business with little to no knowledge of prior methodologies. These IT professionals were brought up on Lean practices, such as Agile and Scrum. The backsliders -- the organizational veterans -- are the ones who introduce this new generation to prior ways of thinking when daily pressures cause them to backslide. Such anti-patterns then become learned behaviors for the relative newcomers, and it tends to stick -- especially when they realize the old methods can work.

There's no easy way to avert backsliding. Such relapses will happen even in the most mature Scrum organizations. Perhaps this anti-pattern is an area where the new generation can shine by noticing when team members start to backslide and then encourage their colleagues to stay the Scrum course.

2. Missed retrospectives

In the worst-case scenario, retrospectives simply don't get done. When teams fail to hold retrospective meetings, it essentially means they will hardly ever improve. Or teams will improve only when they discuss issues, shortcomings and potential fixes over coffee, over lunch or in after-work settings. Such gatherings can hardly be considered a retrospective, especially if no one is taking notes.

When they are held, retrospectives are the birthplaces of many anti-patterns. This is particularly true when the discussion turns to what didn't go well. Teams recognize a shortcoming and brainstorm ways to improve. The proposed improvement sounds great and gets implemented across the next few sprints. And, even if it never meets its goal, it still remains part of the process as an unintentional anti-pattern.

Why would an unintentional anti-pattern stick around? It's likely the team skips a retrospective or two. Maybe there was some turnover on the team, and the new members thought the process was meant to stay in place. Or, perhaps, the team didn't fully understand an intended improvement and either failed to implement it correctly or twisted it into something else. Regardless, now that the anti-pattern has been implemented, it's hard to stop.

The obvious fix to this Scrum anti-pattern is to conduct proper retrospectives and encourage nonjudgmental participation from all team members -- even if this means enabling a form of anonymous comments for what went well, what didn't and ways to improve. Good scribing also helps because it creates a way to share the retrospective notes in editable form.

Also, teams must realize that Scrum is -- dare it be said -- an iterative process. What worked in one sprint may not work in another. It's this constant shift of mindsets that is both the beauty of Scrum and its bane.

3. Inability to recognize the anti-pattern

Sometimes, a team adopts a practice or a tool that just doesn't work well. Rather than identify the practice or tool as the problem, teams instead try to improve the practice or find workarounds within the tool. A better idea would simply be to look for a replacement.

This error is like when a team works with a strong command-and-control mentality. If the manager speaks up at a daily stand-up or retrospective and declares that something needs to be done in a specific way, the team will be reluctant to question that authority, especially if the manager is an active participant in sprints.

Teams may not notice such practices if the daily stand-up morphs into a personal status report where members recap non-Scrum-related tasks they completed the previous day and the ones they plan to accomplish in the current day. These meetings make little or no mention of obstacles or barriers faced in completing story tasks, let alone raising a red flag that the finalized story timeline is in jeopardy. Some individual contributors deem the mention of obstacles and barriers as territory to best stay away from at the risk of being questioned or called out in front of the team. Yet, the purpose of Scrum is to report and resolve obstacles.

There's no easy fix here. You could consider having a knowledgeable outsider help facilitate the stand-up or provide additional training for the current facilitator. Teams can also take a more straightforward approach and have the facilitator ask each team member to provide a yes or no answer regarding their objectives for the prior day and if they expect to meet them for the current day. A no reply is a signal that something probably needs discussion at an offline meeting.

As for the command and control, it takes one or more team members to recognize this is happening and to speak up. The manager may appreciate that feedback.

4. Continuing to work in silos instead

In some instances, a developer may grab or be assigned a story, work on it alone and never consult the product owner or requestor for requirements clarification. This practice creates a scenario where development happens in a vacuum -- with little or no outside input -- and code is eventually handed over to an unsuspecting tester without any design details. Then, a tester dives into the code without first defining which scenarios are the most important to the product owner.

When team members work in silos, it creates issues between developers and testers, which, in turn, affects the entire project. The silo problem can also mean a tester won't collaborate with developers on what, if any, unit testing was done.

It's difficult to break down silos, but it's worth the effort. Stick to small teams, if you can. Call in additional resources as needed. Also, it's a good idea to have all team members participate in iterative demos with the product owner at various stages of the sprint.

5. Failure to improvise

The very thought of creating an anti-pattern causes some organizations to follow Scrum guidelines to a fault. While it may seem safe to keep doing things the same way, repetition goes against the grain of Agile and Scrum.

Remember, these frameworks are based on the goal of continual improvement. Rather than take a calculated risk, some teams get complacent and continue with the ways that have worked in the past.

Other teams decide to live with anti-patterns. Does the fact that anti-patterns linger mean Scrum process improvements stop? Absolutely not.

Ultimately, an anti-pattern isn't a bad thing. It often started out as an idea for improvement or a way for an organization to adopt a Scrum process that fits its needs.

What's important is to recognize a problematic anti-pattern. Take quick action to either jettison it or tweak it so that it becomes the useful practice it was meant to be.