BT

Facilitating the spread of knowledge and innovation in professional software development

Contribute

Topics

Choose your language

InfoQ Homepage News Team-Level Agile Anti-Patterns - Why They Exist and What to Do about Them

Team-Level Agile Anti-Patterns - Why They Exist and What to Do about Them

This item in japanese

Bookmarks

A good scrum master/coach can address team-based anti-patterns, for instance by explaining what less than optimal outcomes arise and what is likely to happen if the anti-pattern remains unaddressed.

Patrick Martin, a scrum master at Neueda, spoke about addressing agile anti-patterns at Agile Tour London 2020.

Agile working practices expose problems in a very stark manner which cannot be ignored. Martin mentioned that some of these problems could be dormant, ingrained into the team culture. In fact, they could be so surreptitious that waterfall’s long phases act to mask them.

Earlier InfoQ interviewed Martin about Organisational-Level Agile Anti-Patterns. These anti-patterns do affect teams of course, but what he defines as a team-level anti-patterns is one that is entirely caused by the team itself. According to Martin, these are relatively easier to address than organisational anti-patterns as there are fewer people needed to put things right than at organisational level, but they can be challenging nevertheless.

Martin mentioned that a vigilant scrum master is essential as they are the radar for anti-patterns. If anything slows delivery down unnecessarily, that’s evidence of anti-pattern(s) at play, he said.

InfoQ interviewed Patrick Martin about addressing agile anti-patterns in teams.

InfoQ: What kinds of team level agile anti-patterns do you see?

Patrick Martin: There are many kinds of anti-patterns at the team level, dozens in fact, but let’s list the top ten (not exhaustive and not in any particular order). A general one would be consistent lack of adherence to the Agile Manifesto’s Twelve Principles, but let’s list some specific ones that I’m sure we’ve all experienced and witnessed:

  • A product owner or PO-delegate regularly refusing or unable to attend Sprint Planning, Refinement, Sprint Review or Sprint Demo
  • Backlog refinement not involving the whole team; usually only involving an internal clique of "tech leads"
  • Sprints regularly being shortened/lengthened
  • Sprint Backlog being regularly changed mid-Sprint
  • Ceremonies not being held or scheduled erratically
  • Retrospectives not fulfilling objectives of continuous improvement
  • Self-organisational principles being breached, e.g. someone allocates work to individuals instead of work being picked up in strict priority order
  • Estimates being amended if work takes longer than expected
  • Estimates being assigned by tech leads, a scrum master, PO or managers instead of solely and collectively by the entire Development team
  • Product Backlog not being prioritised
  • Sprint Goal not formed or unable to be formed

InfoQ: How do anti-patterns compare to impediments or blockers?

Martin: An impediment is typically a temporary, one-time, easily fixable problem, whereas an anti-pattern versus a deeper, more fundamentally rooted phenomenon that is persistent/chronic in nature.

In a nutshell, it’s like the difference between satisfying one’s thirst on a hot day versus feeling thirsty all the time. Both have the same effect, but the former is a one-off and easily fixable, whereas the latter indicates a deeper, more fundamental cause that may be more challenging to fix.

Here’s a more detailed analogy:

Imagine my job is to drive daily from my home to deliver a parcel to a person who lives 200 miles away.

On the way to the person’s house, my journey is impeded by a truck that shed its load all over the road. I am faced with sitting in a traffic jam for two hours until the road is cleared before I can go on my journey.

That’s an impediment -i.e. a one-off, perhaps unpredictable event that is preventing me from making good on my commitment.

An anti-pattern would be why my van is designed to have such poor fuel economy that I have to stop every 10 miles to refuel.

Another anti-pattern could be that no one trained me to drive in the dark and I feel I can only safely drive at 10 mph.

Another anti-pattern is that I have to stop at a town half way to wait on another van driver to give me an addressed cardboard box into which I am supposed to put my parcel. That’s an example of non-cross functionality and chronic dependencies on actors external to my team.

InfoQ: What causes anti-patterns to arise in teams?

Martin: At the team level, lack of adequate training, mentoring and coaching is responsible for a good bit of it, but it is hard to divorce the team from the organisation. Negative organisational culture will of course affect its teams.

Agile can be counter intuitive, especially when it contradicts traditional business experience, but a good scrum master/coach should not only explain a best practice, but should also explain why it’s best practice and should explain what bad things happen if the anti-pattern remains unaddressed.

Some examples in my personal experience: I once worked on a team where a tech lead met with the rest of the Development team immediately after Sprint Planning to allocate Stories to each member of the team. I initially didn’t know this was happening, but my suspicions were soon raised by a couple of things:

  • Sprint Backlog items were not being picked up in priority order
  • The tech lead only worked on the easier items

I asked individuals why they were working on lower priority stories when there was a higher priority story remaining in the To Do column. That’s when it came out in the wash. The tech lead didn’t mean any harm (ok, he was taking advantage of his position by only taking on the easier items, but he was helpful to the others when needed). When I spoke with him, he told me that’s what was expected of him by managers in his previous postings. When I explained to him the reasons why it was an anti-pattern, he understood. I told him he had a valuable position in the team and that it was his role to help others learn from him.

I did a workshop with the team where instead of me explaining why this practice was counterproductive, I asked them what kind of things they saw going wrong, giving clues about prioritisation and multi-tasking. A lively conversation amongst the team later, they arrived at the right answers themselves, the best way in my opinion. The answers are always within. It’s our job as coaches to help people find them without telling them where to find them, but sometimes you have to be instructional and only in very limited circumstances.

Another example was when I took over a team whose Retrospectives were a little lifeless. It turned out that previous retro action items did not result in action items being formed, so they were forgotten about. I changed this by ensuring that we used Trello to capture people’s suggestions, voting format and action items. Action items were put into the Sprint Backlog with owners. This turned things around. People then saw real improvements being made and the team’s faith in retrospective soon became restored and became lively affairs.

InfoQ: How can teams deal with the causes of anti-patterns?

Martin: A good scrum master/coach with the help of workshops, 1-2-1 mentoring/coaching/conversations and day-to-day guidance, can address almost all team-based anti-patterns, but it does take patience, courage and a bit of a thick skin to be frank.

Help create a team spirit. Even if the organisation itself is doing things that it shouldn’t and which are affecting the team, sometimes as a last resort, an "us against the world" attitude can forge strong bonds and a good team spirit, and this in itself can be the catalyst for good things to start to happen in the face of adversity. When team bonds are strong, its people become braver and more willing to challenge poor decision making and actions from others.

We need your feedback

How might we improve InfoQ for you

Thank you for being an InfoQ reader.

Each year, we seek feedback from our readers to help us improve InfoQ. Would you mind spending 2 minutes to share your feedback in our short survey? Your feedback will directly help us continually evolve how we support you.

Take the Survey

Rate this Article

Adoption
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • One wrinkle...

    by Marcelo Lopez,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    The Sprint backlog being changed mid Sprint or at any given time is not an anti-pattern...

    As a matter of fact it is expected that the content of the Sprint backlog change as new things are learned at any time during the Sprint.

    Period. Full stop.

    The thing that the team agrees to overall the most is the Sprint Goal. And the Sprint backlog not only changes but can fully emerge (i.e. can change as, when, what is needed and how to achieve it).

    Earlier descriptions of Scrum, going back to 2005, may have described the Sprint backlog the way as described in this article, but for at least a decade the description of Scrum does not describe the Sprint Backlog functioning that way.

    Oh and one more point.... Scrum doesn't describe picking items from the product backlog in priority order. the ordering described in the scrum guide is the order of delivery according to what will best serve maximizing the value of the product. That may or may not coincide with priorities because something might be a higher priority for someone but yet not derive the greatest value. That's the responsibility of the product owner to decide.

    But overall I applaud you calling out team anti-patterns that are often ignored by Scrum Masters and agile coaches alike.

  • Re: One wrinkle...

    by Marcelo Lopez,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Also...perhaps it's another wrinkle.

    Can we please stop calling these things ceremonies?

    They're events which have a purpose which are not for show.

    Ceremonies are mostly for show and that is their purpose.

  • Product Backlog not being prioritised...

    by Fredrik Vestin,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I would argue that a prioritized backlog is an anti-pattern. The backlog should be _ordered_ or you will eventually end up with everything being high priority. Ordering the backlog forces you to decide whether item A is more important than item B.

  • Re: One wrinkle...

    by patrick martin,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    The occasional moving of items in/out of the Sprint Backlog is ok as changes should be welcomed and reflects the reality of life but if they become a pattern ie a modus operandi as opposed to a mere exception then it indicates something has gone out of control such as managing customer expectations or a culture of reactive panic has set in. If you perform an emergency stop every now and then thats ok but if you’re doing it every day the it indicates either you are over reacting or there is something inherently amiss in one’s environment.

  • Re: Product Backlog not being prioritised...

    by patrick martin,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Prioritization and ordering are colloquially the same thing to most people

    Both terms can be used interchangeably

    Im sure there is a subtle difference that you might care to describe in more detail however. Items or groups of items of higher urgency should be placed higher in the PB than work items or work item groups of lesser urgency.

  • Re: One wrinkle...

    by patrick martin,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Semantics. Once upon a time it was ok to call them ceremonies. Now we are told we should call them events. It doesnt matter

    Lets focus on the things that matter such as making such ceremonies/events/meetings (or whatever name one cares to give them) are held and conducted well to provide the best outcomes for all concerned

  • Re: Product Backlog not being prioritised...

    by Marcelo Lopez,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I respectfully disagree. Those externally exposed to that do not usually (unless the Team goes to great lengths to ensure that they are not) conflated.

    So much so that in more Leadership workshop "rousing discussions" have erupted between peers who have strong opinions about "priority" over "delivery" ordering.

    I respect your experience may lead you to believe differently, but I submit to you that the case I'm posing is by far the more common.

  • Re: One wrinkle...

    by Marcelo Lopez,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Semantics is the harbinger of conflation and obfuscation.

    If you want to call something a ceremony and yet you arrive at the results of the Purpose behind WHY you're gathering together and doing work (which again implies it's not a ceremony)...count yourself fortunate. It doesn't change the fact that part of refining the definition of Scrum in the Guide includes an earnest attempt at "less obfuscation/conflation".

    And as an added point, if someone understand the PURPOSE for said gathering together and doing some work then it behooves you to help others gain a better understanding...after all "uncovering better ways by doing it and helping others to do it", and help clarify the language to remove the obfuscation/conflation. Of course, everyone is free NOT to do so, as others are free to do so (call out the obfuscation/conflation).

    Of course, the inspect/adapt of the Sprint Backlog can and should be classified as doing work.

    Now, if someone disagrees with that statement, that poses a question for that person to reconsider some things.

    This is not to be mean, it's meant to be frank feedback, which is what what my comments were intended to be for the author(s) of the article.

  • Re: One wrinkle...

    by patrick martin,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    One thing that those outside the world of scrum masters and coaches that puts people off agile (and to be frank, some people inside that community too) are arguments about the meaning of words and indulging in almost theological fervour over terms and definitions. If people want to think themselves superior to others because they know terms and definitions better than others, then I worry about what kind of scrum master or coach they are to work with as it belies a form of arrogance and ‘I know the bible of Scrum Guide’. Perhaps its the arrogance and the ‘I know best’ attitudes of many (not all, but many) that contributes to failure of transformation and indeed anti patterns. There are as many forms of scrum as there are scrum teams and each team must find its own natural way to live into the guidelines of scrum (guidelines as opposed to methodological dogma) that results in positive outcomes. The world is awash with great software developed by scrum teams of one shape or another. Im certain none of them do scrum 100% by the book but does it matter? It matters if the team is unhappy, poor flow, bad relationships, unhappy and unmanaged customers etc. If a team is happy then only good things come from such a team. At the end of the day, scrum is about helping put in place practices and culture that elicit harmony. From harmony comes positive outcomes

  • Re: One wrinkle...

    by Marcelo Lopez,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Of course no one "does Scrum 100%" by the Guide. And no one should..Then again, no one should be "doing" Scrum.

    I wish I could remember what kind of argument it is when someone implies shaming using "religious dogma" as a tactic.

    If words, what they mean, and their purpose didn't matter, we wouldn't formalize languages, and teach their use and structure.

    Trying to moralize a rational discussion by appealing to shame doesn't help anyone. This discussion isn't about superiority of knowledge it's about (from my perspective) about sharing further clarity about some things they have shown themselves to be detrimental. After all, this article IS about anti-patterns, and labeling things improperly is an anti-pattern. It's not dogma to refer to things for and by the reason they are described.

  • Re: One wrinkle...

    by Ben Linders,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    @Marcelo words can matter indeed. Purpose matters more, which is something that I read from your answers.

    This is also where I believe anti-patterns can happen if people have different understandings of the purpose that's intended and the goal that we're aiming at.

    On a side note, I recently did an interview on the 2020 Scrum Guide. Asking Ken Schwaber about the changes in the guide, he stated:

    " This updated version of the Scrum Guide is aimed at bringing Scrum back to being a minimally sufficient framework by removing or softening prescriptive language. By simplifying the Scrum Guide, it ultimately makes it easier for people to use."

    I read this as the authors of the Scrum guide trusting the community to have a sufficient understanding of what Scrum is about and giving people space to come up with ways to do Scrum that work for them. Which makes sense to me.

  • Re: One wrinkle...

    by Ben Linders,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    BTW: The full interview with Ken Schwaber and Jeff Sutherland about the changes to the guide and why these changes were needed can be read here: www.infoq.com/articles/changes-2020-Scrum-guide/

  • Re: Product Backlog not being prioritised...

    by Ben Linders,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I'm confused here. What are these discussions about priority over delivering ordering? Do you have a reference?

  • Re: Product Backlog not being prioritised...

    by Marcelo Lopez,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Yes....Ken Schwaber in the PSM 1 class I took close to 10 years ago. Not to mention this is how I actually learned Scrum from those who trained me who were trained by him as well.

    During the class, several people had this "priority" ordering belief, and he went on to state ordering means "something needs to be DONE before something else". This implies delivery (i.e. need) over priority (i.e. urgency).

    People often align the two as equals but they are not always so.

    If someone wanted a "book reference" I suppose I could also search for such as I'm sure that it's out there, but then I'd have to wonder what was really being asked of me.

  • Re: Product Backlog not being prioritised...

    by Ben Linders,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Ok, now I understand how priority and ordering can be interpreted differently.

    I've had several cases where teams treated their sprint backlog as being unordered. They believed that all thing in there were needed, based on that they often worked on everything in stead of first delivering things at the top of the backlog.

    When this happened, I triggered a discussion between the developers and the product about delivering value. That usually helped them to align by using the same language.

  • Re: One wrinkle...

    by Marcelo Lopez,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Full disclosure...one of the translators of the Scrum Guide here (actually I was the first to translate the Guide to a non-English language in 2011 for scrumguides.org) so I know what Ken and Jeff's purpose was for "trimming" the guide, as a trainer I've posted my own suggestions for improvements to the guide along the way to their suggestions queue.

    With regards to Scrum "events" ...they remain as "events" (scrumguides.org/scrum-guide.html#scrum-events), and as Ken and Jeff have defined: "Each event in Scrum is a formal opportunity to inspect and adapt Scrum artifacts."

    If someone feels more comfortable with the word "ceremony", that's fine...it's up to them. That doesn't diminish the point I'm trying to make for others to not arrive at a potentially misconstruable parity between "event" and "ceremony".

    One is the THING with a PURPOSE, the other is a RITUAL you may observe "around" the THING.

    Since this conversation has been around anti-patterns, I felt it important to make this distinction visible, since we're concerned here with the thing and the purpose, not the ritual. Which, since we're talking about the slimmed-down guide, is one of the key reasons why the "3 questions" were removed. People were focusing on the ritual and not the purpose.

  • Re: Product Backlog not being prioritised...

    by Ben Linders,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Based on the discussion with Marcello, I think I now understand what you mean. Preferably the team should work on the highest backlog item and try to finish it, right?

  • Re: Product Backlog not being prioritised...

    by Marcelo Lopez,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Yes!

    This!

  • Re: One wrinkle...

    by Ben Linders,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I guess we're aligned here, purpose and value is what matters and then there are things you can do to get to it. It doesn't work the other way around, that would be an antipattern.

  • Tech Lead assigning stories

    by Philopator Ptolemy,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I know it does sound like an anti-pattern, but it is also true that not all team members can pick ANY tasks. It's a matter of skill, expertise, experience, etc.
    Tech Lead often knows how to deploy available team-members most effectively.
    Also, the fact that Tech Lead took only easy stories makes sense. His main responsibility is to technically enable and support the rest of the team, not necessarily do the work himself/herself.

  • Antipatterns

    by Alex Graven,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    in my experience come from upper management not caring about what "latest buzzword" the dev team wants to use so long as the Gantt chart is maintained in the boardroom and management level, and things are done by when the CEO has decided they need to be done by. So never mind all this "points" and crap, we'll make "points" line up with the deadline already decided by the CTO, never mind backlog, we'll keep everyone working on the deadline because all these "stories" need to be done by the already decided on deadline so we'll fill in time by picking small stories from later we can work on while other people are working on other stories, etc.

    Also, this whole business of "Agile" - I mean, where's the role of the "Architect?", the consultant? How can we plan if we don't have The PLAN all written down and agreed to ahead of time complete with deliverable dates? Agile looks too much like "we'll get it done when we get it done" to people that high up, why not just say "it needs to be done by X, we don't care what you want to call your status meetings, just follow the Gantt Chart."

  • Re: Tech Lead assigning stories

    by Ben Linders,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Wouldn't there be a risk of hampering the self-organization of team members when work is assigned to them by the tech lead?

    I would expect people to be aware of their skills and pick of tasks that they can do, or ask for help with something that's new to them.

    Your thoughts?

  • Re: Antipatterns

    by Ben Linders,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    If upper management insists that everything needs to be delivered by a certain deadline, that sounds like an agile anti-pattern on the organizational level.

    In agile, there's still the commitment to deliver, but it's about delivering the most valuable stuff first.

    I did another interview with Patrick Martin that dives into Organizational level Anti-patterns which might be interesting to read.

  • Re: Antipatterns

    by Marcelo Lopez,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Does the "Architect" develop something?
    Does the "consultant" develop something?
    Does ANYONE develop something that contributes to the value of the product?

    If someone's not seeing a pattern there, it's precisely a matter of education and understanding.

    And if #UpperManagement doesn't care about that, it's a moot point.

    Agile isn't SUPPOSED to be a buzzword. If #UpperManagement is using it as a "ticky mark" on something they want to "look good" to, there's the underlying problem. That's not "agile's fault", that's the people's "fault" (and by fault I mean aberrant, undesirable, unproductive behavior inhibiting the delivery of value to the customer, be they whomever they are).

  • Re: Antipatterns

    by Ben Linders,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Assuming that it the team that delivers: Does the architect support this? For instance by helping the team align on design principles, structure, interfaces?

    Does the consultant help the team delivering? For instance by supporting them to reflect and learn? Develop skills to solve problems themselves?

    And, maybe it's not the role that we need but the activity. People working jointly to define and refine the architecture. Team members pairing up and coaching each other.

    Thoughts?

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

BT

Is your profile up-to-date? Please take a moment to review and update.

Note: If updating/changing your email, a validation request will be sent

Company name:
Company role:
Company size:
Country/Zone:
State/Province/Region:
You will be sent an email to validate the new email address. This pop-up will close itself in a few moments.