Diagnosing Agile Team Member Anti-Patterns

In this blog post, I examine Agile team member roles and explain what I see as behaviors, or “anti-patterns,” that are detrimental to the Agile process.

It is my goal to avoid a negative tone and instead emphasize that these are behaviors that can be changed for the better of the team. However, we can not change these behaviors unless we are aware of them. We are also unlikely to change them unless we understand why certain behaviors may negatively impact a project’s success.

Product Owner

Badly written user stories: Good user stories are critical to a team’s success and writing them can be trickier than people think. Often, for teams transitioning from other development methodologies, getting a balance of brevity and success conditions is difficult but gives the team a strong starting point for feature development.

Unwilling to swap out user stories: A product owner must be disciplined about not adding user stories to a release when that release is already full. It can be challenging to prioritize one feature over another, but it is often a disaster if those decisions are not made up front and more work than is possible to complete is added to a release.

Developer

Not being flexible: A developer who is unwilling to complete tasks outside their comfort zone can really hurt an Agile team’s progress. While it is often most productive to have developers work on tasks at which they are the most skilled, it is critical that everyone is willing to work on tasks possibly unfamiliar to them, when needed.

Not being reflective: The feedback of developers during a Retrospective meeting is important to the continued implementation and improvement of the Agile process. If a developer is unwilling to examine what has been detrimental to them during a Sprint then overall improvement of the team is unlikely. (Check out this Agile Retrospective how-to series here.)

Quality Assurance (QA)

Not closely involved with the development team: A QA engineer needs to be involved fully with the development team for there to be a releasable product at the end of a Sprint. Feedback from the QA engineer at every phase from Planning to Retrospective is key because it removes the “un-agile” barriers that separate QA and development.

Unwillingness to accept automated tests: QA engineers must be willing to understand and accept the role of automated testing. While this can be difficult for some QA engineers that may not have the skill set to write automated tests, they can and should still involve themselves with the people who are writing them.

Project Manager (Scrum Master)

Will not remove blockers: A project manager should persistently attempt to remove/resolve blockers. While a project manager might not directly be able to remove a blocker, they should escalate issues or verify that they have been escalated.

Will not act on Retrospective items: When team members raise issues in a Retrospective meeting, a project manager should immediately act on them. Doing so can result in an extremely positive feedback loop: when a project manager is able to report back to a team that an issue they have brought up has been resolved, it encourages a team to communicate future issues to the project manager. Conversely, a breakdown in communication can occur easily if issues that are brought up remain unresolved or are ignored.

Ignores status: For an Agile project to be successful, a project manager must always be aware of the current status of a team. Unfortunately, a team can fall into the trap wherein daily stand-up meetings become monotonous and key information about what is going on is never discussed or is ignored. While unforeseen events can cause issues with a Sprint, a project manager should be able to notice possible red flags early because they are paying close attention to a team’s issues and progress.

Company Management

Afraid to change the current process: It can often be tough to convince management that the risks of changing processes to support Agile development are worthwhile. It is important that management accepts that there are risks and understand that real issues can be resolved effectively through the Agile process and the resolution of these issues will help the company.

Unwilling to accept “Fail Fast” approach: It can often be difficult for management to accept that the Agile process sometimes tells us to experiment with the understanding that failure is an opportunity to learn. Management must accept that success with Agile may look a little different than it does with other development processes.

Final Thoughts

In conclusion, I would like to reiterate that these anti-pattern behaviors are something that team members can actively change. I feel that the best way to bring about change is to communicate openly about these issues as a team.