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

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.

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.

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.

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.

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.

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

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.

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.

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

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.

@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.

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/

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

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.

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.

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.

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?

Yes!

This!

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.

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.

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."

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?

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.

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).

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?