Walking the board is much more helpful for the team and retrospectives and one to ones can be used to talk about productivity differences, individualities and other issues.
We came up with a variant to fix this. You have to say what the next person in the circle said they'd do yesterday before your talk.
This forced everyone to pay more attention as you don't know who would be standing next to you tomorrow. It wasn't easy to do but I think it did make people more aware of what was going on.
Focussing on the work to be done puts the emphasis on teamwork and skips the pressure on people to justify themselves or play politics by showing off.
That's assuming everyone is doing the work and they're being trusted to do the work. If that's not the case, then you have bigger problems than the format of your daily standup, and standup is not the best time to address them.
The goal is not to explain what you did. Happy with the approach because knowledge is actually spreading across the team currently. Meeting do get much longer though (1 hour usually), but time is recovered mostly on code reviews which become shorter. Usually lot of discussions sprouts out of this, leading to better code overall.
"Worked on adding discounts to the shopping cart page. Went over to talk to Chris in billing about that, and he mentioned in passing that they are planning to move on to SAP next year."
That could be incredibly important information for the team! It doesn't come up as naturally when working through stories as in a round robin.
Personally, I always try to take quick notes ahead of time in order to be able to listen to others during the meeting. I'd highly recommend this to everyone to help focus on what others are saying.
Our 'walk the board' process was saved for tuesdays and thursdays and involved product and project managers. We set a 45-minute max so noone would rabbit hole on any one ticket.
This has been my favourite process so far because this was the highest level of team accountability I've experienced and you would only spend 1.5 hours a week in meetings.
Maybe it's better when you take away the power relations. And reduce the frequency during non-critical periods.
If you don't have pervasive psychological safety, there's a lot of stuff from XP that isn't going to work.
https://youtu.be/OMDQzITWJyU?t=204
From "The Dictator", where Nuclear Nadal is reporting on his progress.
But if I wasn't productive yesterday, I'm not delivering today...
Also, the fact that someone _says_ the focus is on delivery doesn't mean the dramatic focus of the situation is not on whether or not you've "been good" yesterday.
What do you mean by this? Are there significant issues with the management or other devs? This really should be a time where you bring up the issues you're having, and options for others to help you.
Sometimes, tickets just get way underpointed, and I've definitely felt the "on trial" frame of mind, but that's more me putting more pressure on myself. It definitely helps when the rest of the team is asking "ok, you're in a rough spot. What can we do to make it easier?"
Any issues with the management an engineer brings up are issues readily solved with a pink slip for the engineer. "Reading the room" is essential -- understanding the company culture -- before you speak. And even then, you might be wrong.
I mean, if there isn't a manager who can give you orders and personally decide whether you get fired or not. Of course that's not very realistic in a privately-owned, hierarchically-managed commercial company.
I don't have a good argument for the second part, except that I'd attend it to be up to date whenever I could.
Other teams do async standup via Slack, via Standup Alice. It seems to work for them.
I also really like the addition of an "open forum" in my team. Is there anything you've heard from other teams that will probably have an impact on this sprint's tickets or ones in the queue for the next one? Its also a good time for the PMs to relate any relevant conversations had with other PMs that we should know about.
The real key to this is there's no power play involved, and to have a good sense of scope about what's appropriate to bring up and what isn't. We're also a hybrid core/product team, so regular checkins are beneficial overall.
Normal offices accomplish that with water cooler talk and informal chatter, but you miss on that with remote teams. There might be a better way to solve the “loosing of esprit de corps” thing but dailies are the easiest thing I’ve seen do that.
The idea is to be able to share the squishy emotional human bit of working with a team of people.
Without it I've seen people just slowly drift apart. You'd see a comment from a coworker on your PR and be like "argh who is this guys think he is! He's totally wrong" but if you can talk with him about it in video it becomes a lot less confrontational. You can apologise and be apologised to.
A jira board is just a means to have some shared concern to talk about. And done properly can leave you with a feeling of being part of something bigger, rather than a lonely coder talking to a computer.
Programmers: no.
Project managers: Why can't we do this twice a day?
That quote sums it up pretty nicely. To bad of a naming for this type of meeting. Hard to negotiate to do a "daily" less then daily.
When it's work best anecdotally, is when we hold regular retrospectives ON our agile ways of working. EG: Is the standup working for us? What should we stop/start/continue in our standups?
When this 'retro of agile' (rather than just project/product retros) take place regularly you quickly come across a format and cadence that works for the team.
Tools are just tools, they should work for us, not the other way around.
Later during our 1-1, I asked her what the issue was, and she bluntly told me that she thought standups were useless.
I never brought it up again, as she was an amazing developer, and her documentation was absolutely pristine. After that, I myself stopped seeing the value in universal standups. If a person is good, they make it known in other ways.
It's a sad culture when a developer thinks they don't need the team or when, for some reason, they don't have to come to standups.
This for me is the biggest drawback. When you are in the zone and interrupted it takes long to get back in the flow again.
Another point is I don't solve problems in a linear fashion. When I am stuck I sometimes jump to another part of the application that I know I will have to tackle later on. That's just me. This is hard to explain in Agile with a PM/scrum master present.
Edit: PM/scrum master because we have mixed environment.
This is why you do the standup first thing, before people have started working. There is no flow to interrupt.
> Another point is I don't solve problems in a linear fashion. When I am stuck I sometimes jump to another part of the application that I know I will have to tackle later on. That's just me.
If you're doing XP, or any kanban-flavoured variety of agile, you pick up one story/feature/etc and work on it until it's done. You might jump around in the codebase to build that feature, but you work on one feature. That's easy and natural to describe in a standup.
If you're not doing that, then indeed, it's going to be hard to talk about what you've done.
But to be honest, what you're doing is almost certainly not very effective, so maybe stop doing that?
You most certainly don't have enough information to make such a recommendation.
That requires all the people to come to work at the same time.
Jumping between different stories before finishing them is fine in solo projects, but if you're working with others, it means more code conflicts. That said, it is absolutely possible to work on multiple stories in Scrum.
So, basically, what you're really saying is they're not needed and you don't need scrum masters or POs.
PS: in our case SMs and POs are actually doing useful work and we aren't holding any worthless meetings which are solely to entertain people not doing anything. If that was what you implied.
That is exactly what I do. Every morning answer 3 things in Slack. It is also good way to say "Good morning, now I start to work on X, yesterday I did Z and I need some help on Y.
Granted you can always snooze a bit and pretend, but that kind of bad faith is usually indicative of other deeper problems with the team.
Also this can become a drag if you’re “held accountable” rather than “helped in need” but smart leaders would recognize that and attempt to fix the problem in the team, and a daily like that can be a tool for them to diagnose problems like this.
This seems to be an overlooked aspect here in the comments too. Yes, nobody likes to be forced to do something but in this case it's worth it. We have enough distractions as it is so taking 15 minutes to focus on what's important to our colleagues can bring forth valuable connections of ideas and people.
This does really vary hugely from team to team and even project to project though. I fear "agile" methods have forgotten the meaning of the word they are based on at times. Regular re-factoring also applies to development and operational models I find.
Doing it as you suggest is simply doing daily update reports and negates the point of a daily scrum.
I feel often Agile principles are taken as buzzwords without really trying to understand the point. Now, whether the point works for you and your team is another question.
Then you move forward to move say the dailies in Slack, at which point they just get posted whenever people see fit, which sort of works unless the problems themselves need to be solved synchronously, as it is with many cases and they easily just end up being status reports instead of actual planning.
I think it's good to start the day together, with some idea of what everybody is working on. It helps to detect some issues that otherwise might be ignored or detected too late. Generally, communication is good, and short communication is better.
Short is definitely good as is the chance to chip in a bit of unsolicited advice from one dev to another ;-)
Kanban board gets reviewed weekly for assignment and direction (and I keep an eye on it thoughout the week). Blockers get addressed asynchronously in dedicated discussion spaces as soon as they arise. If a solution isn't found in chat then it becomes a topic on the sync meeting. But generally, there's no "spinning wheels" as everyone is mature and doesn't need a short leash.
Which leads me to trust. Everyone in our team has a decent amount of experience. They all know when they are stuck and they all know where to ask for help. I've always felt that trust is empowering and that's what I wish for everyone on my team.
But in this context, 1:1 are very important and I try my best to make them safe spaces for people to bring up issues which would be more uncomfortable to bring up in a group setting, especially for introvert personalities.
Ideally, pick what works best for YOUR team. Experiment and try new things. What works today may not be the right thing in a year. These are tools, not dogmas. The worst process is the one everyone follows but nobody knows why nor how/if it helps.
- Project Manager (Proxy Product Owner) is communicating with the client on a daily basis and is getting some important updates about the progress of the Sprint;
- if there are some unexpected developments (for example, some User Stories appeared to be more complex) the Team and the PO can make a decision about it together, discuss various options, etc;
- the distributed team has a chance to see each other (we were encouraging video calls via Google Meet).
However, there are some certain rules which should be followed in order to make Daily Scrums effective:
- video (or at least audio) conferences for distributed teams – it can actually be slower to have this meeting via Slack;
- they must be timeboxed (15 minutes max);
- stay pragmatic about what you are discussing and ask the feedback of your team about it.
If a team isn't well-functioning, then daily scrums could have some value -- but I think a better approach would be to fix the team.
It worked great. We ended up doing a quick meetings 1-2 times a week to sync-up and get the idea of where we are. Any blockers would be brought up informally (through Slack or in-person). We all knew each other well, so trust was high to begin with. Also, it was a relatively small team of 5 people.
I guess the point is that "having daily standups" is not agile. Regularly asking yourselves if they are or would be useful (whatever the answer may be) is.
Title: Is [x] better than [y]?
Article: Depends on context
