DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
  1. DZone
  2. Culture and Methodologies
  3. Agile
  4. Diagnosing Agile Team Member Anti-Patterns

Diagnosing Agile Team Member Anti-Patterns

From product owners to quality assurance, learn the different behaviors that can be detrimental to an Agile team and what can be done to correct them.

Joshua Robinson user avatar by
Joshua Robinson
·
Jun. 21, 16 · Opinion
Like (1)
Save
Tweet
Share
2.79K Views

Join the DZone community and get the full member experience.

Join For Free

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.

agile Anti-pattern Project manager

Published at DZone with permission of Joshua Robinson, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • Ultimate Guide to FaceIO
  • PHP vs React
  • Building a Scalable Search Architecture
  • An Introduction to Data Mesh

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends: