Stand-Up Meetings Are Status Meetings. This Needs to Change
Photo by Hannah Busing on Unsplash
The Secret Developer seems to have an issue with Agile. This has grown into quite an issue with a person whose behavior has gotten worse and worse over time.
Today’s rant? It’s about Agile standup meetings. There should be an opportunity for a self-organizing team to get together to solve software development issues. To resolve issues and report progress.
What could be wrong with a 5-minute slice of time where the team meets to discuss progress?
“I have started to have the attitude ‘another day, another meeting’. I feel that my only verbalization in a standup meeting has become Blocked.
Sure, it’s because the CI isn’t working. Brilliantly we test the Backend through the frontend so a whole host of people are sitting idle and saying blocked in this particular stand-up.
To be honest with you the whole thing has degenerated into a status meeting and nothing ever gets resolved. So what is the point?”
Background to The Agile Stand-up
Stand-up meetings are designed to keep an Agile software team informed and connected. It’s one of the Agile ceremonies and helps push the team towards their goals.
“I claim that they have become a forum for management to make sure things are ‘on track’.
When things are not going well the solution is often for the stand-up to go on for longer. Ours is too large (almost 30 people) so this can go on for 30 minutes or longer.
I can’t see the point. If there is a problem software devs should fix it. Ask for what you need. Get it done.”
The Issues
“I want to break down the issues for you before I get onto what can be done to improve the state of affairs in Agile software development. Let us take a look! “
The Faulty Stand-up Structure
“The age-old agile drill is a well-worn script. Don’t worry; nobody really cares what you are doing or how you are feeling.
The issue with this is that the questions lead to rote responses that just give a status update. The structure better lends itself to a status update written in a ticket. That’s not acceptable.”
Standard questions that require a response in an Agile stand-up meeting:
What did I work on yesterday?
What am I working on today?
What issues are blocking me?
The Passive Participants
Nobody is listening to the responses from their fellow developers. This is my wide experience. When you hear someone saying:
‘I’m working on TS917, merged TS913 yesterday’
It is actually spectacularly boring.
Not only that. The next day they might say the same thing, and nobody will take note. More realistically TS917 might be a dependency for someone’s work and saying ‘I’m working on it’ is considered enough of an update for everyone. When it’s done the completion is only communicated in the morning update perhaps wasting a working day for those dependent on the work.
It’s almost as if nobody is listening.
It’s almost as if nobody cares.”
Solutions
Actually Trust Developers
Imagine a world where software developers were trusted to get features developed.
“Every day I do what I said I would. If something goes wrong, I write a message on Slack to get what I need. I am able to communicate when something is done to let the people waiting for a change know.
I think that would be closer to a ‘self-organizing’ team but what do I know? I’m just a developer.”
Keep on task
The Agile stand-up should be for the development team to discuss progress and remove blockers.
“Children in school aren’t chased for work as much as devs in companies. The wasted energy to keep asking team members what they are doing is frightening.
Developers frequently speak about tickets that are entirely unconnected to the team’s day-to-day work. Like refactoring a single class in their code. No wonder it is boring as it just isn’t relevant to other people in the meeting.”
Small Teams
An Agile team should be 5 or 6 people strong. This removes some of the issues described in this article immediately.
“It seems that the practice of not remembering what one another is doing in a team could well be contributed to by the massive team I’m working in.
It also contributes to my sense of alienation in the team. It’s not good all around.”
The Product Manager
The product manager represents the retail customer of the product. Yet oftentimes they see their role as one to remove the blockers from the system and allow developers to do their work. This can also be a role taken by the scrum master.
“Rather than removing blockers these types ‘run’ meetings where the developers are quiet.
Worse in places I’ve worked, developers do lie about progress and the reason they’re not moving JIRA tickets right.
Either the people in roles should take charge of the situation (and gain tech knowledge to) or they should remove themselves from the situation entirely.
I’ve seen a developer claim they worked all weekend to make an oneliner code change. They get away with it because those running the meetings lack tech knowledge.
I mean do your role properly and rein in devs, or don’t do it at all.”
Conclusion
”I don’t want to admit this, but I feel there is an easy root cause for this and making the changes above isn’t going to make a real change until we address the actual issue.
Many companies are not doing Agile correctly. They are dressing up waterfall as Agile. Until we accept that many of the ceremonies and work is going wrong. “