Rethinking Stand-Up Meetings: A Call for Engagement in Agile Teams
Written on
Chapter 1: The Stand-Up Meeting Dilemma
Another day brings another stand-up meeting where we discuss our progress on the current project.
Blocked
Currently, our Continuous Integration (CI) system is down, and the backend is overly dependent on the frontend. It’s somewhat ironic that we test the backend via the frontend; consequently, when a bug arises, at least three team members must gather for a meeting— in addition to our stand-up and other Agile ceremonies.
We all enjoy Agile ceremonies, right?
Background to the Agile Stand-Up
Stand-up meetings are intended to keep Agile software teams in the loop and cohesive. They must have some value, don’t they? However, I argue that under certain conditions, these meetings have become platforms for developers to exhibit arrogance about their roles and their peers.
The Issues
The Structure: Flawed
The classic Agile routine of asking:
- What did I accomplish yesterday?
- What am I focusing on today?
- What obstacles are in my way?
is becoming ineffective.
You may wonder, "What do you mean it's ineffective? We follow it daily!" Ah, but that might only be your perspective.
Many developers do articulate what they have done and plan to do; they adhere to the format. They even mention the issues they face.
So, what’s the problem?
The Participants: Passive
In my extensive experience, many developers fail to truly listen to their colleagues’ updates. Common responses include:
“I’m working on TS917, merged TS913 yesterday. Waiting on Rajit to complete his ticket before I can proceed.”
This exchange creates an illusion that everything is functioning smoothly. You might even receive a follow-up about whether Rajit is holding up TS912. So, all is well, right?
Not quite.
The following day, no one revisits the previous day's discussions. If you don't bring up TS912, Rajit, or anything else, it’s as if no one cares.
Developers often discuss tickets that have no real connection to the team's immediate tasks, like refactoring a single class in their code.
It Gets Worse
The Process: A Lack of Engagement
No one recalls what was said the previous day, and there’s no follow-up on earlier tickets. This behavior gives the impression that the work being done doesn’t matter. Why not collaborate to ensure the team operates at peak efficiency?
The goal should be to enhance productivity.
In the absence of genuine engagement, it’s easy for team members to zone out and disregard their colleagues’ contributions. Introducing games into the process won’t address the core issue.
Solutions: Trusting Developers
Imagine a scenario where software developers are trusted to deliver features.
"I fulfill my commitments. If I encounter a problem, I reach out on Slack for assistance."
In schools, children don’t have their teachers constantly monitoring them, yet in tech companies, we tolerate this oversight. Where does this energy to micromanage originate?
The Product Manager's Role
The product manager acts as the voice of the customer. However, many view their role as merely removing obstacles so developers can work.
“You know, in my experience, some developers tend to bend the truth.”
They often spend excessive time "helping" colleagues instead of focusing on their tasks. Simple bugs can turn into hours of investigation, and claims of changes taking a weekend may stem from a single line of code.
They manage to evade scrutiny because product managers rarely have visibility into the code repositories.
Moreover, many developers operate as lone wolves. The spirit of teamwork has faded, resulting in significant industry challenges.
When developers’ tasks are fragmented into tiny tickets, disconnected from both the business and their teammates, they often lose interest. The collaborative aspect of their work has diminished, leading to numerous issues.
Conclusion: The Path Forward
Historically, developer engagement has been low.
That developer who "forgot" the stand-up due to "chilling" while working? I genuinely believe he thinks I take that at face value. Yes, we understand why you switch off your Zoom camera during stand-ups.
This is concerning.
Encouraging software developers to assume responsibility and be diligent in their tasks should be integral to the interview process. Until we prioritize these qualities in candidates, the industry will continue to experience mediocre performance both individually and collectively.
When team members work together, everyone benefits. It’s a pity that fostering a culture of teamwork within Software Development seems so challenging.
We should strive for collaboration, after all.
About The Author
Professional Software Developer “The Secret Developer” can be found on Twitter @TheSDeveloper and regularly publishes articles on Medium.com.
This video discusses the importance of safety stand-down meetings in creating a culture of accountability and engagement within teams.
In this video, learn about the essential follow-up actions required after a safety stand-down to ensure lasting impact and continuous improvement in team dynamics.