I'm sure this won't be popular with the devoted, but I find Scrum, Kanban and daily stand-ups a huge waste of time. It's funny how rigid agile becomes when you can make a lot of money making it rigid through consulting dollars.
The converse is also true though. A lot of things will get resistance because people don't like to change, or they'd rather not leave their desk and talk to other people, or they only want to optimize for their personal productivity without considering the productivity of the team as a whole. That last one in particular is the source of a lot of friction with developers in my experience. Individuals like to optimize for their own personal productivity, and sometimes in order to increase the productivity of the team the individual productivity needs to suffer.
So as long as you're being mindful of your practices, what you're doing and why you're doing it, and looking to constantly improve the output of the team as a whole then feel free to adopt what makes sense and discard what doesn't work, and ignore anyone trying to sell you on dogma that they barely understand themselves.
This makes a lot of things click into place for me. I've consistently seen it be a struggle for people to buy into the activities that may not immediately make things easier for the individual, but are necessary for the team, myself included. Stating it this way cuts right to the essence of why those activities are vital.
Disagree only in that you need some rigidity for some time in order to get consistency and value. Agile dictates that this time-boxed rigidity should be routinely inspected and adapted over time. Does that make sense?
More of my views here https://leanpub.com/agileforleads/
We started out differently than most teams, where we began with a very loose process and tightened it over time (as opposed to many who start out very rigidly and let them slack over time) and this has led to us:
1. Predicting with surprisingly good accuracy (within 10% usually) how much work we can get done
2. Spending only ~3 hours a week doing "rituals" (we do our stand ups in HipChat and we have two backlog grooming sessions a week; every other week we spend an hour for review/retro and an hour for planning), which gives us an overhead of ~8% time "wasted" doing our planning
3. onboarding new members in only a couple of weeks; we plan so that they always join mid-sprint so that they get a solid week to just read up on our code and observe our process before jumping in for their first planning
4. creating a really cross-functional "everyone works on everything" team; for my part, I spend most of my day in the weeds of Kubernetes for a variety of projects, but I'm able to cross-train on the other components my team works on, and I'm slowly teaching all of them K8s.
I won't call it "agile" because it's a dirty word apparently, but I really like it now that we've spent a few months hammering out the kinks.
As always it depends on many factors, so I wouldn't be quick to throw out absolutes.
There are much more efficient uses of communication when direct communication isn't required:
- Email
- Messaging service
- Backlog queue
To me, it's just ritualistic for the sake of ritual.
No ifs, whens, or buts?
That said, you are preaching to the choir here.