What? I’m not privy to RedHat/IBM/Google’s internal processes but they are all massive FOSS contributors at least some of which I assume are using Agile internally. The Linux kernel is mostly corpo-backed nowadays.
The development cycle of FOSS is highly compatible with Agile processes, especially as you tend towards the Linux Kernel style of contributing where every patch is expected to be small and atomic. A scrum team can 100% set as a Sprint Goal “implement and submit patches for XYZ in kernel”.
Also agile ≠ scrum. If you’re managing a small github project by sorting issues by votes and working on the top result, then congratulations, you’re following an ad-hoc agile process.
I think what you’re actually mad at is corporate structures. They systematically breed misaligned incentives proportional to the structure’s size, and the top-down hierarchy means you can’t just fork a project when disagreements lead to dead ends. This will be true whether you’re doing waterfall or scrum.
What? I’m not privy to RedHat/IBM/Google’s internal processes but they are all massive FOSS contributors at least some of which I assume are using Agile internally. The Linux kernel is mostly corpo-backed nowadays.
The development cycle of FOSS is highly compatible with Agile processes, especially as you tend towards the Linux Kernel style of contributing where every patch is expected to be small and atomic. A scrum team can 100% set as a Sprint Goal “implement and submit patches for XYZ in kernel”.
Also agile ≠ scrum. If you’re managing a small github project by sorting issues by votes and working on the top result, then congratulations, you’re following an ad-hoc agile process.
I think what you’re actually mad at is corporate structures. They systematically breed misaligned incentives proportional to the structure’s size, and the top-down hierarchy means you can’t just fork a project when disagreements lead to dead ends. This will be true whether you’re doing waterfall or scrum.