Problem is in practice, I suspect something is pretty wrong in most teams.

Some common examples come to my mind:

• Management hears “talk about what you’ve done and what you will do” so great time to sit in and take notes for performance review, and it becomes a “make sure management knows you spent all your time and did really impressive stuff” meeting. Also throws a kink in “things I need help with” as there’s always the risk that management decides you aren’t self sufficient enough if they hear you got stuck, so you also need to defend why you got stuck and how it isn’t your fault.
• The people who feel like everyone needs to know the minutia of their trials and tribulations including all the intermediate dead ends they went down on the way to their final result. Related to the above, but there are people who think to do this even without the need to impress management.
• The people who cannot stand to “take it offline” and will stop everything to fully work a problem while everyone is still ostensibly supposed to stay in the meeting despite having nothing to do with the two people talking (sometimes even just one, a guy starts talking to himself as he tries to do something live).
• Groups that are organized but have very little common ground. An “everything must be scrum” company sticks a guy who does stuff like shipping and receiving into a development team and there’s no ‘scrum-like’ interaction to be had and yet, there he is wasting his time and having to talk about stuff no one else on that meeting has a need to hear either.

You’re bending your team/process to fit agile, and not bending agile to fit your team/process

Yeah, this one is tricky.

If a methodology is supposed to help, but you don’t change your processes in any way, then it seems odd to assert that you are “adopting” a methodology.

In fact, I would say that the typical dysfunctional Agile shop basically “bends agile” to fit their process, meaning they undertake a superficial exercise to map a problematic process to Agile terms and declare victory. Sometimes taking the time to actually make the process worse in a way they wanted to, under the smoke screen of “Agile transition”. For example, in my company customers are generally using our projects together, so we had basically a set cadence of release dates. All projects were only allowed to target designated release days (March 1st, June 1st, etc.) A project, if it made sense could skip a release window, but the projects wouldn’t just release 2 weeks differently than all the related projects. Project owners declared this “not Agile” and said everyone just release whenever, much to the complaints to customers that now have a barrage of updates that are in no way synced up, with QA that tried to use the projects as the customer would abolished, so until the customer there’s no one using the “current” editions of the projects together in one place. Agile is perfectly happy with a prescribed cadence (in fact I would say usually I hear the mantra that you try to fit your work to the schedule, rather than letting the work mess up the schedule), but development managers didn’t like the way the release schedule tied their hands so they blamed Agile for a really bad quality move.

I’m all about processes that fit your team, I just think fixation on Agile branding does more harm than good.

In our case, tossing stuff in the backlog to never get done is just part of trying to get through life.

We have an… eccentric colleague who demands the craziest stuff that no one else wants. Now in a sane world, we explain that his requests are either extremely costly for a minor thing no one cares about, or, like 90% of his requests, run explicitly counter to what our customers want even if we could trivially do it. He is not a customer nor is he in contact with customers or marketing or sales, he’s in a different technical team but has an “armchair enthusiast” interest in my teams product.

We used to try to have that discussion to reject items to make it clear they will never ever get worked on. However whenever we did that he would demand hour after hour after hour of meeting to discuss each request that we want to reject and convince us why his requirement is the most awesome thing in the planet, and with enough meetings maybe we’d stop being so clueless and come around to recognize the brilliance.

So now we toss it in the backlog, and there’s always a point of comparison like “Customer giving us $40M asks for feature X”, and he has to rationally accept why X jumps ahead of his backlog items, even if he is displeased. One new project manager made the mistake of trying to close out the backlog items and the meeting invites flew about us daring to ignore his awesome requests.

So we have a chunk of backlog that every one knows will never happen, and in fact if our backlog ever dried up, then we’d have a big problem because then we’d actually have to have that tough conversation about why his ideas are bad. At this point some of his wacky stories have been on the backlog for over five years.

That’s about your team and/or your teams leadership, not scrum.

While true, that cuts both ways, a successful team is not successful because of ‘scrum’, it’s successful because it finds a methodology that works for them, which can be in terms of scrum, but even if no one was chanting Agile buzzwords, that team would still self organize in a similar way, just without the precise buzzwords.

What’s obnoxious is that a lot of folks, with a vested interest in, say, consulting, will give credit to “Agile” for teams succeeding and then simultaneously call all failures that ostensibly use Agile but fail “not true Agile”. It can be harmless enough when self-organizing, but then it doesn’t really matter if it is “big-A Agile” or not. People hung up on the “big-A Agile” may be expecting to cash in with consultancy money, or use it as a club to assert their authority by their self-proclaimed alignment to ‘Agile’. They are advocating for Agile, therefore if you challenge anything about their direction, they will invoke the magic Agile word to silence criticism about their methods. Once an organization has “acheived Agile”, ironically they frequently close the door on any consideration of methodology reform. “We are running Agile now, whatever you may think we are doing wrong the industry agrees with us because the industry uses Agile, so stop complaining”.

So Agile may be technically workable, but the frustration is that it is vague enough to allow anyone to do almost anything and still ‘fairly’ claim Agile, but as a brand word it confers unreasonable authority for certain folks. As the most prominent brand word in the world of project management, it is further correlated with the ‘default’ asserted methodology of any crappy group looking toward consultancy/self-help to fix their bad team situation with a bandaid of methodology.