1. See success
2. Want success
3. Copy behaviors
4. Behaviors were only part of successI'm going to say this rather rashly (and maybe regret it sometime in the future): any "Agile" process that includes a status meeting for developers is broken. Status should be determinable from the artifacts that have been produced. If management can not see or understand the artifacts, then your process is broken. If they prefer not to look at the artifacts, then your management is broken. If they need status on something that is "taking too long" then you haven't broken up your tasks enough. If you have broken them up enough and it's still "taking too long", then there really isn't much to say other than "this blew up on us" -- which is obvious.
What a standup is good for is casually checking with your teammates that the approach you are taking is reasonable and to discuss other strategies. It's useful for asking for help, swapping pairs (or getting one in the first place). If you find yourself doing the "This is what I did yesterday. This is what I'm going to do today" dance, then you are not getting much value. It should be blindingly obvious what you did yesterday, because code was written, reviewed and hopefully merged. Possibly you may want to say, "Hey, can you review my code?" It should be blindingly obvious what you are going to do today, because you grabbed a card/task from the backlog. The only thing you need to talk about is, "I'm confused. How do I do this?" and the like.
/end rant ;-)
Hell yes! Status meeting can be a band aid while you get people to properly document and communicate those though. You often don’t need the whole team for that though.
It's a bit of a joke.
I think experimental evidence helps, but if you look at the physical sciences more closely, you'll find tons of similar narratives. This is a fairly universal human behavior unfortunately. Nonsense becomes "canonized" as I put it, and then continues to be repeated by people until someone finally looks into it and realizes it's nonsense and publishes an article saying so. But unfortunately that's not always the end of the nonsense. Even things which have been debunked can continue to be cited and used. One great example (not engineering but the point stands):
https://www.youtube.com/watch?v=WRoe3xXFtmM
> In one sense we won. We got our points across. People now understand that this research is wrong. But this 2005 article by Fredrickson and Losada gets citations today at 3 times the rate of our article that demonstrated that it was just utter rubbish.
(Note that I'm using "nonsense" as an example here, but the top level comment was more general in that it mentions practices which apply in some situations erroneously being applied for all situations.)
No doubt there will be arguments for how oracles for ethereum are different, and so on
* Early adopter independently comes up with an idea that works well for his/her team.
* Writes an innocent well-written article or book.
* Idea somehow becomes dogmatic. Even for situations that don't make sense.
* After some time, people rebel against dogma because they realize it doesn't make sense for every situation.
* Original idea now considered anti-pattern even though it may still make sense for some people or situations.