Some Thoughts As I Sit Here in Another Standup
I’m writing this while I wait for this morning’s exercise in futility: the daily standup. I opened my editor with the intent of documenting what a complete waste of time standups are and I realised that adding an entry for all five of this week’s standups would give more insight into how the industry is afflicted by deep cultural malaise.
I don’t like Agile or Scrum. To be exact, I don’t like fake software project management cargo cults1. Specifically, I am referring to Agile not agile - note the capital letter. This single letter, when used by organisations and so-called thought leaders, is a litmus test.
The distinction is crucial: agile, with a lowercase “a” represents the mindset and philosophy of adaptability and continuous improvement as described by the agile manifesto in 2001. On the other end of the scale, Agile, with a capital “A” has morphed into a rigid, prescriptive framework that organisations adopt superficially. Scrum is a part of this too, which has been absorbed into Agile so much that no one can really explain the difference.
I posit that if I showed the Agile Manifesto bullet points (without the title) to a group of people with cringe-worthy titles like Scrum Master, Agile Delivery Manager, Agile Coach, or Head of Agile Delivery, and asked them “Is this agile?” almost all of them would say it isn’t. I can only imagine the effect that revealing the title and explaining that, actually, this really is the agile, would have on their Jira-addled brains.
Organisations have taken agile and turned it into a beauractatic checklist exercise. Have you noticed how they often give speeches and fancy presentations with phrases like “doing Agile”? Yeah, not being agile, but doing Agile. I’ve written about this before in my article on how many teams are forced to give fake estimations to satisfy management and executive “leadership” teams2, even though everyone involved knows it’s all a sham.
Back on the topic of standups, and before I write more about my disdain for how the software industry is actively sabotaging itself, I’ll quote perhaps one of my favourite blogs on the internet.
Those apologists who insist that Agile works very well for them - you can leave now with my blessing. Half of you have only worked at functional organizations, and you’re best off not knowing how most of the world lives.
Which absolute fucking maniac in this room decided that the most sensible thing to do in a culture where everyone has way too many meetings was schedule recurring meetings every day? Don’t look away. Do you have no idea how terrible the average person is at running a meeting? Do you? How hard is it to just let people know what they should do and then let them do it.
I am telling you right now, the average 15-minute stand-up runs for 30-60 minutes, every fucking day, and absolutely jack shit is accomplished, other than everyone delaying work until the stand-up is over.
Reading this for the first time was incredibly cathartic, relatable, and so true it hurts. Standups are like every other cargo cult “ceremony” (seriously, what is up with that word?) where the people running them expect, miraculously, a different outcome to the previous ceremonies.
#NotAllStandups and other apologetics
Every day, we are expected to repeat the same mantra: “Yesterday, I did the work I needed to do. Today, I will do the work I need to do.” Nothing of value is gained from this. If I have a problem or need to work with someone, I’d message them directly - not wait til the next morning’s standup.
You may be thinking, “Aha! Got him! #NotAllStandups! Proper Agile and Scrum do not work this way, and standups are perfectly fine; maybe a few organisations do them badly.”
Well, what is a few? One? Two? Five? I can categorically attest that standups run this poorly in all of the jobs I have had. Speaking to many developers and reading accounts of disastrous agile, scrum, and standup practices assures me that I am not alone and in fact, in the majority.
I’ve seen this cycle a few times. Let me handwave how it goes:
Agile Criticism: The snake oil is all over and getting worse!
Agilista: It’s not done properly!
Agile Criticism: No True Scotsman!
Monday
Today is the last day of the sprint. I’ve completed all my assigned work. Normally, I’d just pick up more work from the backlog and just do it without asking, estimations and “sprint refinement sessions” be damned.
Often, by the time a meeting concludes to decide how much effort a task takes, the task could already be finished. However, since it’s the last day, I don’t want to take on tasks that will likely change multiple times in the immediately impending sprint review and planning, thanks to indecisive stakeholders or the typical milieu of company politics.
Isn’t it ironic that, by being truthful, I’d be signing myself up for extra inconsequential work between now and the sprint review? To protect myself and the team, I need to bend the truth to avoid defaulting to stupid work. That’s the crux of this; the industry is rarely truthful. If it were, it would reflect on why people need to defend themselves against this sort of default stupidity in the first place.
Nine - yes, nine - minutes in, the standup properly starts. It proceeds with its usual infantilization of software engineers. In this team, rather than letting adults discuss their work and give updates voluntarily, the Scrum Master nominates a “temporary Scrum Master” for the day’s standup based on alphabetical order. This nominated Scrum Master then reads Jira ticket titles verbatim and prompts the assigned person to discuss them.
You might think I made a mistake by mentioning a Scrum Master nominating a temporary Scrum Master. Unfortunately, it wasn’t a mistake. In the original idea of Scrum, there was no permanent position of Scrum Master, and each day a different engineer would run the meeting.
Yet, here we are with a full-time, permanent Scrum Master (some places have started calling them Agile Delivery Manager). So, if we have that person anyway, they may as well always run the meetings - but they don’t. Their sole job appears to be getting someone else to do their job.
That sounds a lot like a scene from Office Space, which remains the most accurate portrayal of software engineering project management I have ever watched.
After this segment of the standup finishes, I know precisely nothing new about the progress of anyone on the team, and what I did glean from the monotonous ceremonial chanting of Jira tickets being read verbatim, has absolutely no impact or consequence on me or the work I have planned.
In fact, the main theme of this standup was “the PR is in review” and “the work is waiting for QA”. Thank you, I feel very informed and updated. Keep it up.
Thankfully, the standup is coming to an end. Various stakeholder types spend the next several minutes discussing everything but software development matters. Standups were originally supposed to be exclusively for the people writing the software…
Did I learn anything that will impact my day? No.
Did my updates impact anyone else’s day? No.
The call ends. I closed my eyes, took a deep breath, and then stared out of the window for a moment.
Tuesday
The first few minutes of today’s standup revolved around a discussion of who is ill, on holiday, or unable to attend the meeting. Like most “standups” that are masquerading as standups, this is actually a team update or some other appropriate name.
Did you know the actual Scrum Guide advocates for only allowing the developers to participate in the standup? Non-technical stakeholders may observe. Unless you’re a glutton for punishment, you’ve probably never read it and so wouldn’t know that.
Of course, agilists happily gloss over that part of the Scrum Guide, because standups would be radically different if they were - the kind of different that’s good for developers, which automatically makes it the wrong kind of good, so agilists won’t tolerate it.
We engage in the same game of “Who is next in the alphabet?” to nominate the temporary scrum master and I start to feel that all too familiar sense of futility and déjà vu.
One person, A, starts giving updates on behalf of person, B, who isn’t able to attend the meeting. Hang on, this sort of thing happened yesterday too. Person B could post an update in one of the Teams or Slack channels - asynchronous communication. Instead, we’re stuck with this garbled game of Chinese whispers3 which is informing precisely no one about anything meaningful for the second day in a row.
Also, isn’t the point of those Jira tickets to track progress? If someone isn’t able to attend, then surely the tickets are enough to at least infer the progress. Is it the same or a different status from yesterday?
Today is also what I have named “Meeting Tuesday” where we have a standup, a sprint review, and a retrospective all in one day. Those are also deservingly of ridicule, but a topic for another time.
The meeting proceeds to a discussion about user stories. Someone asks “Do we have any user stories for the API?”, and I start zoning out, wondering once more how any of this makes sense.
Wednesday
Another standup, another “Who is next in the alphabet?”, followed by verbatim reading of Jira ticket tiles. Today the next person in the alphabetical order was the actual scrum master, so they ran the standup.
The conversation almost became too risqué when a technical discussion about an API we depend on came up. I could see the scrum master was itching to pull the trigger and say the classic, “This conversation is becoming technical. Can we take it offline?” Yuck. Imagine if developers actually talked about software engineering in a meeting originally intended just for them.
Today, our standup was merged with the sprint planning meeting. Nothing says “this is a valuable meeting” like just throwing it into the start of another meeting.
Even though it was only yesterday that we had “Meeting Tuesday” with a sprint review and retrospective meeting, for some reason we have a sprint planning meeting today.
You may be wondering what the difference is. I simply don’t know. Ask a group of developers and agilists alike, and they will all give you different answers.
A recurring theme in the software industry is that management is often simply making it up as they go along under the guise of Agile. Everyone claims to be doing things The Correct Way™. Sure, there’s supposed to be a difference, but this sprint planning meeting is just rehashing the same topics, including story point estimation, that we discussed in the sprint review yesterday.
The meeting progresses at the speed of drying paint. It was brought up that Jira highlighted we had completed forty-three story points in the last sprint, instead of the expected forty-six. Also, Jira is suggesting that next sprint we should be aiming for thirty-six completed story points this sprint. This is, of course, so that burndown charts and other fancy charts look good in various stakeholder and management meetings.
This brings to mind what I discussed in my article on estimation.
Even if the burndown chart is totally inaccurate as long as it’s a perfectly linear line that’s all that seems to matter for organisations “doing agile”.
As the meeting drew to an end, we were asked to think of a sprint goal. I audibly sighed at this - fortunately, I was muted.
I decided to volunteer an answer: “Our sprint goal should be to complete the work.” They thought I was joking. I wasn’t.
I strongly disagree with the principle of a sprint goal, as it’s a meaningless “scrum ceremony.” Here is what the infamous Scrum Alliance has to say on the topic:
A sprint goal is the predetermined objective for the sprint outlined in one to two sentences that give purpose, direction, and focus. Sprint goals should be targeted, quantifiable, realistic, relevant, and time-bound.
Consider the diverse nature and scope of the tasks each developer is working on. Summarizing these various efforts into a single meaningful sentence is usually impossible. Even if developers are working on overlapping features, the sprint goal would still be reduced to a simplistic and uninformative statement. Ultimately, the only valid sprint goal is “to complete the work,” which is so obvious and redundant that it renders the exercise pointless.
Thursday & Friday
I condensed these two standups into one entry. There was nothing new here that I didn’t already cover. Just the same perfunctory nonsense.
Both standups were equally uninspiring - if I wrote more, it would be repeating the same points I’ve already made. Which, again, highlights the stupidity of it all. Thankfully, even the most insufferable agilists seem to have had their fill of smelling their own farts by the end of the week, so Thursday and Friday standups tend to be shorter, sometimes.
Writing all of this down has reinforced what I already knew; this is all performative work, just like the majority of the whole Agile/Scrum framework and its many processes and meetings. The entire framework is all for show, and almost everyone knows it.
This parody of productivity is an insult to the experience, skills, and knowledge of developers. The complete hypocrisy of subjecting everyone to all of this while claiming this somehow increases collaboration and productivity when it objectively does not is infuriating.
I can’t believe this is considered the pinnacle of the software engineering industry. It makes me sick.