I've spent 8 years working under some manifestation of Agile methodology:
All of these years I had some Agile shaman herding me around and boasting to management how much the team did. There was always more boasting than actual work completed.
Every time I criticized Agile, even in a constructive manner "that specific thing just didn't work for us", I got to hear the "well you just didn't Agile right".
As with most popular things, the underlying values and ideas behind Agile are pretty cool:
Cool values, but apparently everyone gets them wrong.
One of the few things Agile excels at is generating endless burn charts that mean something to some people.
If I were to draft an Agile manifesto based on what our Agile shamans did, it would look like this:
Maybe that is what bothers me the most - meetings and committees.
They say "every meeting has to have a purpose" but let a meeting become recurring and it becomes a ritual. A couple of weeks go by and your day is 40% meetings that you "listen-in just in case, oh and provide some feedback when you can".
Then they pump out committees faster than teams deliver features:
And that's just the first week! Next week they'll create a committee to oversee the QA, security, documentation, code formatting, tool selection and of course a committee to oversee the other committees.
What happened to "letting people talk to each other"? They are talking, look at how many meetings we have
Do we really need to create "spaces for people to talk at"? It's facilitation, silly
Do we really need to obfuscate decision making? Committees know best!
Do we really need to gamify work to "make it engaging and motivating"? But it's fun!
Stop treating your colleagues like kids.
You want to motivate developers? Give them clear goals, interesting problems, involve them in decision-making, recognize their work.
You want people to talk to each other - let them try. Don't "facilitate" their communication - it's extremely important for people to learn when and how to reach out to other people.
Every "Agile" project I worked at had a problem of people "collecting things for the stand-up". They do some work, encounter some problem and stop working altogether because now they have something for the tomorrow's call.
Promote effective communications. Recognize when developer delivers something. Involve motivated people in design, let them feel a part of their project, not a cog in a machine.
Stop micromanaging. I know how fun it is to "solve other people's problems", but you're not allowing your team to grow.
Identify champions in the team. Involve them when there are battles to be had:
Not only will your champions be the best representatives for the corresponding areas, they will feel recognized and, hopefully, appreciated.
Give and gather feedback. Listen to concerns, collect ideas, resolve conflicts. Know what's in your power and make sure your colleagues know what you can do.
Don't be afraid to let people go. Don't abuse it, but if a person doesn't want to change or is not aligned with the
team, it could be in everyone's best interest for them to become somebody else's problem find a different team.
Learn when to take responsibility and when to let others take it.
Don't treat your work like a "clock-in / clock-out" - you spend half the day with your colleagues, promote good vibes.
Stop "just kicking the can down the road" even if your shaman tells you to. Always look at a bigger picture when kicking the can - at the very least kick it in the right direction.
Let your manager know if you want interesting problems (or if you're not interested in problems you're working on).
Let your manager know if you want to do things "outside of your role" (public speaking, conferences, open source).
Ask for clarifications if something is not clear, don't wait it out.
Ask for help without waiting for "the next stand-up". Also offer help when able.
Speak up if you don't like something about your work. Don't vent, just talk to those in charge, be it a shaman or a manager.
If you're in senior/lead/architect position - allocate time for emails. If you don't want to attend some meeting, suggest resolving it via email and provide your inputs immediately. Quite often an email is enough, but even if not - you're already driving the conversation where you want it.
Be the change you want to see in your project.