Whether they’ve written it or not, I’m willing to bet that nearly every developer with a certain amount of experience under their belt has a rant ready to go about Agile. As such, I doubt anything I say here is particularly new. It’s just my personal take.
I often say I love Agile. That shouldn’t be much of a surprise; look at how much I’ve written here or on social media about optimizing processes and iterating (not to mention specifically using Trello to do so). People who I’ve considered to be mentors are very involved in the Agile community (though I, myself, am not) and I’ve taken lessons from them to heart.
I love the idea of self-organizing teams. Coming together to not just build software but define how the team works builds cohesion and shared ownership.
But also, over the last several years, I’ve come to the realization that some implementations of Agile methodologies really trigger my anxiety. For awhile it was easy to brush that aside as Agile having been implemented incorrectly but I have to wonder how much I’ve been falling back on that as an excuse.
I do want to call out that the fact that I’m writing this now is not a criticism of any singular employer or team that I’ve been a part of. My thoughts have solidified in recent years because – after a relatively long period of stability – I’ve been on a bunch of different teams across a handful of employers, which has shown me that some things I thought were unique weren’t quite as such.
In my experience, it is specifically the various flavors of Scrum – with its emphasis on rigid time-boxing in the form of sprints – that are particularly anxiety-triggering for me.
I’m a big fan of the idea that the work takes as long as it takes to get done. There are too many variables; we can’t know how long it’s going to take until we’ve actually done it.
If we want to estimate the amount of time it’s going to take to get done, that’s great. If we want to estimate the amount of effort it’s going to take to get done, that’s even better. But that’s just an estimate. It’s a guess. A hopefully-educated one but a guess nonetheless.
When we start taking estimates of work and turning them into estimates of time, and then turning those into commitments, I get anxious.
We’ve gone from “I think work will take this much effort” to “I am committing to get this work done in a specific amount of time even though I might not know everything about the work.” I know that I don’t know everything necessary to make a commitment but our operating framework requires that the commitment be made. And maybe we kind of wink and nod and say that we know sometimes stuff happens and it’s okay if we don’t meet those commitments but at the end of the sprint we inevitably total up what got done vs. what we committed to and talk about how we can do better going forward.
We talk about sprint capacity. We figure what our teams should be capable of in a perfect world and we plan our sprints around everything being perfect even when we know every sprint can’t be perfect.
Not completing what we commit to feels like failure. Much like how failing fast is still failing, failing when we know it’s not that big of a deal is still failing. It feels bad to fail. We don’t want to fail. And, even if we wink and nod and say that we know stuff happens, we set ourselves up for failure.
Knowing that, just going into a sprint with that commitment triggers my anxiety. I might have trouble focusing on the task at hand because I know that if I don’t get that task done quickly enough, it’ll impact the two other tasks I’ve committed to sitting in my backlog. It makes me feel like I can’t take a sick day if I still have stories in progress because I committed to getting that work done and I don’t know that I can afford to lose a day against that commitment.
This is nothing new. Ron Jeffries referred to some of this as “Dark Scrum” nearly a decade ago.
That can be mitigated, though. At the end of the sprint, rather than “Did we get all the stories we committed to done?” we can ask “Were there any stories that we failed to estimate appropriately?” It likely still gets into converting an effort estimate into a time estimate but we can try to leave some wiggle room in there for understanding that effort is not time. If we see any stories that seem like outliers, we can look at them and their unique circumstances to see if there’s something we can learn from them.
Sometimes there is something we can learn. An assumption was made that shouldn’t have been and we can iterate with that new knowledge. Sometimes the story took longer than expected because of sick time and we don’t need to change anything. Sometimes the story took longer because it’s just a particularly hairy part of the codebase and we all knew that might happen. None of which are failures.
Then there’s the daily stand-up.
Ideally, a stand-up is about quickly identifying and resolving blocked work. That’s supposedly why it happens every day. Too often, it boils down to a personal status meeting. “What did you do yesterday and what are you working on today?”
Already anxious about getting enough work done, this begins to feel like a daily attempt to justify my effort. Am I, in fact, working hard enough? Already feeling like I’m behind, am I successfully explaining why that is? Having planned our sprint for full capacity, do I actually feel like I can interrupt someone else’s work to get help if I need it?
If we plan for our sprint and assign stories on Day One, then stand-up on Day Two is where we’re already asking if that work is complete yet. Of course not, I just got it yesterday. Later on Day Two I get pulled into meetings that take up my afternoon. Then the same question is asked on Day Three. I have a good reason but, no, it’s still not done yet, and we’re nearly a third of the way through the sprint already.
This is just a theoretical scenario but its one I’ve lived, where a single afternoon lost to meetings throws off the early efforts in a sprint, with things snowballing from there.
Changing how the stand-up works won’t change overbooking individual team members or failing to plan for impromptu meetings but that doesn’t mean there’s nothing we can do to change the focus of the meeting.
The stand-up can, instead of being a report on the status of each team member, be a report on the status of each ticket, highlighting what needs to happen to keep that ticket moving. And maybe the answer is nothing because that ticket is being worked on with no blockers, the work just takes time to complete.
Or maybe the stand-up doesn’t need to happen every day. Tying into the above idea, it takes time to complete work and maybe we shouldn’t expect there to be an update on work every day. That said, my personal experience is that when I’ve felt particularly anxious about reporting to the team on a team that doesn’t do a daily stand-up, I’ve found myself taking mental health days on stand-up days.
As I said, I do think a lot of my anxiety comes from having work time-boxed. That can’t be entirely avoided. Sometimes there’s simply a hard due date that has to be hit.
We can work with that, though, by doing away with artificial due dates. That’s why I prefer Kanban to Scrum, combined with a stand-up that focuses on the status of the story rather than the status of the developer.
By abandoning sprints, we avoid the anxiety of completing a certain number of story points in a certain amount of time. Instead of committing to doing a set of stories in a sprint, we commit to doing the work on our plate as professionally and efficiently as possible.
Estimation is still important because we have to communicate outside of our own team. This does require a change in how we communicate, though. Instead of “That will be done two sprints from now.” we say “That is fifth in our backlog. We estimate the things in front of it to take X amount of effort.”
We still retro at a given cadence. We can still look at if stories are taking longer than we expected and iterate on our estimation. We just stop asking if we got everything done that we expected to. We stop committing to things we don’t actually have the ability to commit to. Instead of a wink and a nod, we codify it in our working norms. This frees everyone to be available to work on the highest priorities as they come up.
If our organization actually values self-organizing teams, maybe that’s the end of it. We noticed some patterns that weren’t working for us and iterated, shifting to something that works better.
But, speaking from experience and cynicism, maybe our company doesn’t actually value self-organizing teams. Maybe we’ve fully-embraced Dark Scrum and, rather than as a tool for organizing, it’s meant to be a tool for control, with deadlines and methodologies dictated from outside of the team.
And in that case, I legitimately don’t know how to influence change.
