Why Scrum is stressing you out

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.

It's kinda nuts how many capital-A Agile processes (and consultants!) produce situations that are diametrically opposed to the original ideas. Notably, Scrum is often processes and tools over individuals and interactions.

You need some coarse odometer to know where the finish line is. Burn-up charts are a reasonable input to that and can be very low effort. Just knowing where you hit the inflection point between new-issues added to a milestone vs. issues resolved is useful. If you can replace a burn up chart with tangible test results matrix or similar - even better.

> retrospectives

I have never found per-sprint retros useful, either. I guide teams to do a retro when the issues raised in the previous retro are resolved. WIP control FTW.

> poker sessions

In my experience, planning sessions are one of the most impactful parts of the stereotypical scrum process for three reasons: (a) Planning creates a consensus within the team about what the story actually means; (b) Planning often leads to someone proposing a good 80/20 trade-off or raising an important point that avoids future re-work or unexpected tech debt. (c) Breaking big tasks into actionable, independently useful, small tasks is one of the hardest things for junior developers to learn. A lot of mentorship and teaching happens in good planning meetings. I encourage teams to try planning for the benefits of the process and not worry at all about fine grained points - "trivial", "medium", "unknown" is typically enough. Lots of mature teams will plan ad-hoc as they are ready for new work. This is my personal preference. But teaching teams how to plan effectively in a weekly planning meeting is often a good starting point.

> daily stand-ups

Standups that are control points for managers and expensive status gathering shortcuts are horrible. standups that are self-organizing, especially for teams that have ops + dev responsibilities, can be really useful. Nothing wrong with making a plan for the day - it should just take 10m.

> user stories and related tickets (eg in JIRA)

You should write down what you want to do somewhere and a few checklists go a long ways towards improving quality management.

I have never found scrum to be a good process (like the article, I find it very grinding) and I strongly agree with the posted article. But a good dev process likely includes all of these elements in some shape.