I can’t help but feel that every different flavor of formalization of the process of collaborative [software] development feels… nearly the same? At the end of

I can’t help but feel that every different flavor of formalization of the process of collaborative [software] development feels… nearly the same? At the end of the day. Whether there is a self-conscious attempt to avoid being accused of dogmatics, or alternatively a fully embraced biblical dogma, it all feels like the same basic advice repackaged in new language. Sometimes the formalism is meant to create a framework to help the team organize better, but… I feel like it all just comes down to: - above all, be consistent but not too rigid - talk with your colleagues, keep up to date with each other - think about your constraints and goals frequently and check in with how you are relating to them - work hard but not too hard - have some systems, any systems in place, to check for poor work product and highlight good work product. What is good work product? Well, to use the famous quote, you’ll know it when you see it! To be fair, some frameworks may obviously help some teams more than others, but like any tool evaluation and selection process, it always seems so highly contingent which process management method might work well or not, many might work equally well, and most of it comes down to the team and people more than it does the system… I could be totally wrong as I don’t have much experience in teams or orgs beyond 5-10 people, but still… just my surface level understanding of all this. I’m curious what others on here with far more experience and exposure to a variety of organizational frameworks have found and think about my assessment.