Assuming you have a Kanban board for your work, and assuming the work is actually accurate on the board in terms of status (which most teams are terrible at without practice) AND assuming you properly have “waiting for testing” “testing” “waiting for review” “reviewing” columns (those waiting for columns are critical to seeing the true state of work), then you simply just “walk the wall” from right to left. As you scan through each column, team members call out if shit is a mess, otherwise you just get a thumbs up and move to the next thing.
Then, just use some analytics to highlight tickets stuck in a status too long, and bubble those up in the standup. “You keep saying this is on track, but it’s been here for a week, what’s the deal?”.
STANDUPS ARE NOT STATUS UPDATES. They’re for resolving blockers in person without letting shit linger too long.
As long as your board is accurate and respected as the source of truth, it is the status update mechanism. It’s no longer a human job.
(And yes, this is actually possibly, my agility team does this with 15+ scrumban teams right now)
Which means "real" standups are completely useless. Let's say we have it every day at 9:30 and I get stuck at 11:00. Does anyone really expect me to wait almost a whole day to get help, or should I just go talk to someone about it right away like a normal adult would?
So... what type of question or blocker is so unimportant that it can wait for a day to get resolved, but at the same time is so important that we need the whole team to stop working and discuss it?
2. You don’t discuss problems at a standup, you make your team aware (if you haven’t already) and organise a separate session with only the interested people.
Exactly my point. We make the team aware of problems of blockers via Slack (team channel), so there is no point in making the team aware again of such blockers in the standup.
Granted, most scrum masters have no idea what they're doing which likely leads to individual team members not seeing fulle value in Agile rituals, but it is there.
- To see who's working on what, I just look at the board. - To seek help when I get blocked, I send a message on Slack (or whatever) at the point that I need that help, not only at 9:30 AM - To know who's blocked on what, just tune to Slack
Given the above and if you have the team discipline to make sure that tickets reflect the state of work. Why do we need standups then?
That time can be more targeted towards a meaningful discussion, but the industry seem to be blindly just doing that without giving it much deeper thought. It baffles me.
“Individuals and interactions over processes and tools”
Doing standups for the sake of it is adherence to a process over the needs of you’re people.
Equally, a core principal of agile was always:
“The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”
And I think it’s always worth considering if your truth is the same for everyone on the team. This is actually something I’d bring up in a review (assuming you have those too right?). If you all agree that notifying and handling problems in Slack is enough, that checking the board is sufficient the just do that? What is stopping you?
I would also look for actually data too back it up. How often are people blocked. How do they get unblocked. How long does that take. Etc. Gives you some insight into the reality of the situation and some ammunition to get things changed if you’re team isn’t really being agile and is just doing the corporate software eng dance.
If standup’s aren’t solving a clear problem for you, stop doing them.
Have you spoken to your lead / manager about why you do them? How do the rest of your team feel?
If you always know who can solve every problem for you, then you’re either not doing very interesting things or you’re burning that person out, and Management (including the engineering team leads) needs to know this.
The standup would be the safety net when people don't see that they're stuck, know what to do and are afraid to ask / hands down in smth they just don't see the obvious.
Uncovering this in a standup should prevent them from "wasting time" even longer.
I have rarely seen this in my experience so far; either people aren't as dumb as people believe or they know what to report to not fall into this "let me take over here, you seem to have messed up" category.
Exactly. If you're starting to get stuck and you're afraid to ask for help, the last thing you're going to do is making that obvious in front of the whole team and/or your boss. If you didn't believe you can manage it on your own, you'd have asked for help already.
Often these issues just linger until you finally talk to your manager or team about them. Having a regular opportunity to do that can speed up the process.
A blocker or unforseen problem that you have already overcome but a) have been delayed by and b) might be of interest to the rest of the team to learn from, even if it is just for curiosity.
An example might be "this has been delayed because I discovered the underlying service is a mess and needed a good deal of changing to support the function we thought it already supported. That's now done - grab me after for details if interested - and I am now back to implementing the stuff in the story but it's been a full day of unexpected extra work."
In 2012, I was on project were we used a physical board, and we would make a black circle for everyday on the board and once we started exceeding the initial estimate (it was done in days as opposed to complexity for some reason) we make that in red, then we started discussing the reds
Which make standups useless. If I have blockers I communicate them right away. I don't wait until the next standup to do so.
A standup encourages people to solve their own problems as best as they can, and to aggregate their interruptions to limit the number of individual interruptions throughout the day. Without a system like this, a team’s senior engineers may get nothing done besides assisting others.
The answer to that is yes. But only if you have someone with the authority to interrupt when it goes off-track. I frequently do that, but it usually takes a very long time to convince the people I work with that someone needs to have this authority(interrupting people is usually considered rude, whereas unrelated rambling is really the rude part by being disrespectful of all the people that are not interested in it).
On paper I thought that that's the role of the scrum master. But in practice I've never seen a scrum master do that. I usually offer this to the project owner, but usually the project owner is the one rambling the most in standups.
Practically speaking what happens is that when people start rambling I interrupt and tell them to take the discussion to the 2-3 other people that need to discuss this with him/her after the meeting.
The idea is to make the connections needed with the people present, to help with the issue after standup (Bob is having issues with authentication on API x, and Sally says she might know how to help. They will take this up after the meeting).
Status updates should also not go into detail. You might be proud of your very cool efficient implementation for a sorting problem, but get your ego stroked someplace else please (PR's are a good place for that).
Most important of all; empower every team member to shut down this kind of time wasting for the rest of the team, by simply saying that this kind of talk should be taken up after the meeting.
Me and my team and a financial institution do this, and it does not matter who is in the meeting (PO's, executive directors etc).
that's true, but it just turns the question into the one of "is it possible to do real standups?". My experience is that I've never managed to do real standups. It's just not possible to relay complex information about what you're doing in 1 minute. You either do it so superficially it's worthless or you it in depth and it takes longer than a standup should.