I think this a well made point that many developers fail to appreciate. Some processes are there to make people productive, prevent them from distractions and

I think this a well made point that many developers fail to appreciate. Some processes are there to make people productive, prevent them from distractions and help resolve issues... ...but an equally important set of things you’re doing is providing estimates and feedback to the business, so they can make strategic plans and not look stupid to customers. A lot of process fails (particularly in agile) seem to stem from failing to understand why they’re being done. Retrospectives aren’t for planning technical debt sessions; they’re there to explain why you didn’t deliver on time. You made some bad estimates? Well, if you don’t go back and review them, guess what, you’ll never get any better at it. Were those deadlines arbitrary? Maybe, but aren’t you glad you didn’t have to sit in a meeting explaining why things won’t be delivered when you said they would, and oh yes, how stupid you are and so very sorry, its not good enough is it. Those are meetings no one wants to have. If you’re forcing your workmates to have them by half heartedly doing a process, your team isn’t doing their job; even if they’re highly productive and produce high quality output. Scrums aren’t a tech briefing. No one really cares what you did yesterday. Its your chance to ask for help if you need it, and a chance for the team to make sure everyone is on point and not drifting off into Q-space working on something irrelevant. Basically, whatever the process, people don’t just magically ‘get it’: you have to actually articulate what you’re doing, and who’s benefit it is for, or its a meaningless mess of going through the motions.