9 ms·

I'm also 15 years in and have worked at all different kinds of companies with a few different kinds of processes, and I don't really relate to this. To your po

I'm also 15 years in and have worked at all different kinds of companies with a few different kinds of processes, and I don't really relate to this. To your point: I don't think any senior engineer argues that it is tenable to have absolutely no process. There needs to be a way for business stakeholders to communicate with engineers and vice versa and for everyone to plan and contribute to prioritization together. But many senior engineers debate the time scale on which and the audience with which that coordination and planning and prioritization should be happening. The threads here where I've seen the most pushback are where people have been advocating for processes that are designed to give very broad audiences very nearly real time insight into what engineers are doing with their time. And I think that's pretty bad and I think lots of experienced people agree with that, not just whiny youngsters. What I support is small teams where intra-team visibility is not really an issue, and cross-team coordination on longer time scales (bi-weekly, monthly, quarterly, half-ly, I've seen all of these work fine, with different trade-offs).

sirsinsalot 4y ago
I don't disagree with anything you've said. My core point was that process, of whatever form, is right and necessary. I've seen things go wrong due to no process and I've seen things go wrong due to inappropriate process, and any process applied poorly. The process isn't the evil, it is poor leadership, regardless of the process that kills projects. Different projects in different industries, with different software IC contributor types calls for different leadership ... and I've used Scrum and others successfully as tools in that leadership. Blaming tools (like scrum) or any tool blaming I feel is immature and scapegoating. Granted my original post was a touch inflammatory, partly out of frustration. I made my living repairing under performing teams and good processes top to bottom are the number one thing I've found that stabilises things and turns it around.

sirsinsalot 4y ago

I don't disagree with anything you've said. My core point was that process, of whatever form, is right and necessary. I've seen things go wrong due to no process and I've seen things go wrong due to inappropriate process, and any process applied poorly. The process isn't the evil, it is poor leadership, regardless of the process that kills projects. Different projects in different industries, with different software IC contributor types calls for different leadership ... and I've used Scrum and others successfully as tools in that leadership. Blaming tools (like scrum) or any tool blaming I feel is immature and scapegoating. Granted my original post was a touch inflammatory, partly out of frustration. I made my living repairing under performing teams and good processes top to bottom are the number one thing I've found that stabilises things and turns it around.