| It seems like HN has gotten one of these posts every month or two for as long as I've been reading it (about 15 years now). They always make me some combination of sad and angry, because they almost always misdiagnose the issue. Process isn't the enemy. The various named and defined processes are just tools. It's all in how the tool is applied. And while this post wrongly blames a process, it does get one thing right: > If a development team were to sit down and decide to deliver code every two weeks, based on a process of their own design—one that made sense to them and suited their circumstances—that would be one thing. [...] Autonomy—the ability to direct one’s own work—plays a significant role in how work is experienced. The development team (which ideally includes design and product as equal members) should be deciding its own process collectively and with a high degree of autonomy. Scrum, Kanban, Scrumban, Waterfall, "no process", these are just the defined and tested tools we select from in deciding our processes. We can mix and match them, draw from them as needed, or throw them out and try something new. But we as a development team should be deciding, together, what process to adopt in order to achieve the businesses goals with the resources and time as best we can without burning ourselves out. --- I was a full stack IC for 10 years and an engineering manager for 5 years. I've done more or less all the processes. I'm currently back to being an IC in an org where Product dictates exactly the sprintless "no-process" this post is advocating and it is every bit as stressful and bad as he's claiming sprints are. The best team I've been on was one where we had full control of our process. We started with scrum-like month long sprints, of which the first week was planning week where we did deep dives on our stories, wrote them up and ended the week with the scrum planning ceremony and agile pointing. We used an "ideal day" as a point to give our estimates some level of concreteness, but largely stuck to our recorded velocity. And you know what? It worked! We got surprisingly good at estimating and, while we were never perfect, if we overran our sprints it often wasn't by much. Planning week was definitely rough, and we eventually chose to ditch it in favor of two week sprints with planning stories worked into the sprint as needed. That worked really well too (and I think that's my preferred process). But the point was, we choose these processes. We ran these processes. Our retros were vibrant and highly critical discussions where we asked ourselves every sprint what was and wasn't working and made changes. When I became a manager, I carried this forward on my teams. We iterated through the two week sprints with planning SPIKES, to continuous flow kanban, and back to two week sprints with planning SPIKES. When I became a manager of managers each of the teams in my org choose its own process. One stuck with the scrum-link, one adopted kanban, and one (the smallest) decided to throw it all out and go with "no process". Each made their respective process work. Each had different challenges, because no process is perfect. Each continued to iterate on their respective processes. And I worked with the leads - the manager and staff engineer of each team - to form the cross team processes and communication to ensure that each of these autonomous teams could still collaborate. Process is not the enemy. Process is just the structure of our collaboration. It becomes bureaucracy only when someone else is dictating that structure and preventing us from structuring our collaborations in the ways that best work for us. |