Is anyone’s team here fully Agile and how has that been so far? My team is currently in sprint 0 and I’m already tired of the meetings.

Point of the meetings is to create shared context and consensus. Do you see it happening ? Or do you just do the "ceremonies" and nobody is mentally invested in actually achieving anything.

I've been in multiple teams as consult and certified scrum master.

I think you are confusing terms. Agile is not about meetings. It's about showing the customer progress regularly and a short feedback loop.

Scrum is one of the many way to achieve this and has a lot of meetings.

You can work both scrum and agile. But you can also work scrum and waterfall or agile and kanban.

What are the things you dislike?

Not meetings. *Ceremonies*!

Those meetings should be informative, short, focused, to the point and not a minute longer than necessary.

If any of the above aren't met, it's being done wrong.

Fully agile? What does that mean?

@rytzpekt We do have people(developers) mentally invested in the meetings but getting hold of the product owner who is on the business side is another issue because they're mostly busy.

@bahua arrghh, I forgot. Yes, ceremonies T_T

@asgs Haha, everyone seems to be doing a "form of agile" but no one is "truly agile"

@Codex404 Thanks for the explanation. It makes sense what Agile methods want to achieve (my team just started the journey). I see a lot of scope creeping and changing requirements which might be extra work for developers. Early feedback is good but what happens when users change their mind in the middle of a project and we have to re build everything? Also devs are no longer shielded by the BAs meaning constant negotiation with the users directly. Issues like these.

@jennytengsonM We also have this issue where our product owner and back up product owner are very busy at certain periods. Its a good idea but the implementation is quite the headache

@Afrohacker if you show the customer the new things you made in the last two or three weeks then you don't have to change that much.
They have given a description and only once it's clear you start working on it. Then when it's done you show it to the customer and most of the times they should agree. Sometimes you need to change one little thing.

If you don't work agile the feedback would get back when you think you are done. By then you would have to start over completely.

If you have to change to much between sprints then it means that:
A) the customer requests are unclear
B) the customer is constantly changing their mind
C) you are programming it in a way changes are barely possible

@Afrohacker

The solutions are:
A) ask the customer questions to clarify. Explain examples and why you think it's better to do it one way.
B) Before you start working the customer has agreed to the definition of the tasks. If they want to change things that is fine but it will be more development time and thus costs them more money.
C) you have to think before writing code. Seperate features should not depend on each other. Rewriting a single feature should not take to much time.

There's no such thing as sprint 0.

Scrum is a heavyweight process, which seems to contradict Agile but actually doesn't, like @Codex404 already explained.

For me personally Scrum's too heavyweight, I don't need its hand-holding. I'm glad that currently I'm not working in a Scrum team. To be frank I found it pretty annoying. The probably biggest offender is the daily stand-up in the morning, where my mind is fresh and I'd prefer to stay in the zone. Instead I was made to listen to stuff I either already knew or that didn't concern me.

So, from the Scrum teams I was part of, the best one still dreaded reviews and backlog groomings. Retrospectives were fun. Well, until the team lead decided that photos of our whiteboard should be stored on the company Wiki for everyone to see, and noone dared to say anything remotely critical anymore. The other meetings were in between.

@VaderNT scrum meetings don't have a time of day.
If you want to do the daily stand-up after lunch or at the end of the day that is fine too. The morning is just a suggestion because for most people that is the best time.

Retros shouldn't be shared with other teams like you said. Retros are team specific so that information is useless for outsiders.

@Codex404 "If you want to do the daily stand-up after lunch or at the end of the day that is fine too"

I agree. I do want to have a late daily stand-up, but I seem to be the outlier. I guess the argument I hear the most is "when done in the morning, we can concentrate on working the rest of the day".

Superficially that sounds reasonable. OTOH mornings are the most productive time. At least for me and most devs I work with. So I'd prefer to do it when you're "low on energy" anyway. But... yeah, outlier, most people still are against it or don't care.

@Codex404 "Retros shouldn't be shared with other teams like you said. Retros are team specific so that information is useless for outsiders."

I wouldn't argue it's "useless". Some managers love surveillance, so getting a photo of what was discussed "behind closed doors" is very welcome. In that environment I described, I've seen a higher manager asking about a rather negative point of a retro later.
It's understandable - some managers are afraid of losing their power. So in their mind, it's necessary to ensure noone objects, everyone obeys, etc.

Instead I'd argue that the openness and honesty of the discussion suffers if you have to "watch your mouth".

Agile is just the current version of shitty management processes used to provide a lot of people with useless jobs. The most important similarity between it and previous iterations of shitty management processes is that some people will find a way to get things done despite it. They will accomplish this by bypassing or violating the rules.

@monkeyboy next time know what you are talking about literally nothing in your comment makes sense.

@Codex404 I absolutely know what I'm talking about. I've worked with agile ( scrum and Kanban and various custom flavors) for parts of 2 decades at multiple companies). I've been a certified scrum master. Prior to 2000 I taught classes on TQM within my company. My experiences and opinions may very well be the polar opposite of yours, but I damn well know what I'm talking about.

@Codex404 BTW, comments like yours are exactly the same from decade to decade. THIS time, we're doing it right, and any other opinions are uninformed or just plain wrong.

@monkeyboy well you are using terminology wrong. Agile has nothing to do with management and all about short feedback loops.

Heck I can just grab start with anything that pops into my head without a customer interfering with it. When it's done, show it to a customer to get feedback - > it's agile.

From a certified scrum master I expected the capability to not confuse terms.

@Codex404 "Agile has nothing to do with management" is demonstrably false everywhere but in academia. I'm glad you can practice the way your second paragraph hints at. But those environments make up a vanishingly small number of actual places. In short, you work in a fantasy land. Enjoy it.

@monkeyboy it is not how it is for me. But that would still be agile.

Agile is great no matter what. Scrum, kanban, whatever else is personal opinion.

But I cannot imagine someone preferring waterfall over agile.