I think for this to work well, it needs to be with someone you don't feel the need to impress. Maybe you have a teammate you trust like that, or maybe you can find a coworker on a different team who doesn't impact your performance assessments. If you have that, this feels different than a standup. Standups easily devolve into signaling to the team that you've done work. Instead, a 1:1 meeting with a coworker who you don't feel the need to impress makes it way easier to be vulnerable and admit when you screwed around on the internet for a lot of the day.
If the culture is right, it's enabling. If the culture is wrong, it's patronizing. It's not intended to be a public accountability ritual; it's intended to make it so you're participating in setting the expectations of the team, and if you're not living up to them, the team looks to figure out how to better support and enable you.
You can't fix culture with (just) process, but process certainly affects culture. And this kind of process directly contributes to a culture where people are pressured based on how they work at an extremely finely grained level. Even if somebody is doing top-notch work and having real impact long-term, if they're not making legible progress day-to-day, Agile is going to make them look bad and feel bad. The process itself emphasizes consistency and incremental work while deemphasizing individual flexibility and agency.
Now, perhaps some teams have a culture that's strong and accepting enough to compensate for this and provide a great environment for people who work in different ways, but if that's the case it's despite the process, not because of it. I've never seen that myself though.
And, it really doesn't contribute to a etc. I've had devs spend days with basically the same status, but it also was a large task. I've had devs make incremental progress, and everyone understood. I've had devs (and been a dev!) who said "I got nothing done; I was in meetings and they drained me", and it's fine (though it helps highlight that the meetings are too much very early).
The process presumes culture. It assumes the team functions together and is aligned in delivering, and isn't looking to blame one another. If the culture is bad, then, as with any bad culture, it's easy to blame the process.
Why do you phrase it as "public accountability ritual"? I'm sensing my definition for accountability is different than yours. I typically think of my comment at a standup as (small) opportunity to answer "what have you been working on?" once instead of if every member came by and asked in a friendly manner. I wouldn't be bothered by them asking individually, and it saves me repeating the answer.
I've never heard the phrase "isn't living up to expectations" related to stand ups. Do you (or places you've worked) normally have those related? I'm not sure I understand.
Why do you think it's "in front of your team" as opposed to "with your team"?
I, and other people I've worked with, have never been bothered by saying "still working on the same hard task" for _weeks_. If anything, I usually hear encouraging comments; "it sucks that the task is so difficult", "anything I can do to help you out?", "I'm surprised you haven't gone crazy from that", etc.
The places I've worked at aren't even great at agile, but I've never seen the process directed towards some of the things you're saying.
This incentivized breaking everything up into tiny tasks and getting things out the door instead of getting the right things done. It was not a good workplace.
Second, just to point out (I'm sure you realize, but just in the spirit of the parent comment), no agile workplace cares about the load of tasks dev has. Are they busy doing valuable work? If not, is there valuable work they could be doing? That's it. If yes to the first, no problem. If no to the first, and yes to the second, no problem, "hey, I've got something you can have a look at". If no to both, no problem, it's on product and management to work on getting some new work items.
Maybe just bad luck and bad workplaces, but I am increasing skeptical that there are any true 'Agile' workplaces.
That said, agile is, if anything, a culture. It's why it started with a manifesto, and it's why retrospectives are the only meeting that is spelled out in it; the retros aren't to try and determine what parts of a particular process you're not adhering to, but what isn't working (process or otherwise), so that you can change it (i.e., "At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly").
There are plenty of workplaces that have that culture, even if the processes are all over the place. Of the last four workplaces that called themselves agile that I've worked in, three of them had that culture, and I and my teams got amazing work done in them (in fact, my reason for leaving at least one of them was -directly- due to the hiring of a micromanager and the ousting of someone who protected the teams from upper management). The fourth was an old school enterprise company you've almost assuredly heard of, with high employee retention, a culture of top down management and decision by committee, and, surprise surprise, their injection of agile processes did nothing to make them actually deliver software any faster, nor did it lead to any better results.
You work just enough to have something to say that day. Rinse and repeat for the next day. The incentive isn't to do more or better work. The incentive is to have something impressive to say at the next meeting.
The other issue with standups is if it's not "on the board" then developers are disincentivized from doing certain things (proper testing of code, code reviews, etc.) in favor of things that show up.
> The other issue with standups is if it's not "on the board" then developers are disincentivized from doing certain things (proper testing of code, code reviews, etc.) in favor of things that show up.
If important things are missing from the board, that's a problem with the planning process.
It's easier than it sounds to simply put those things up on the board. If engineers realize something important is not on the board, they need to get it up on the board. Communication needs to go both ways in planning sessions.
It wasn't too hard a discipline to keep, I think it helped a lot to use physically different space and hardware.
A good first step is to understand what's fundamentally different about working from home, alone, versus working from the office. Some common differences:
- Context shifting into the office can help context shift you to work mode. At home, if you use the same workstation for games and Reddit and work and entertainment, you lose the physical context shift. If possible, try using your company-provided computer for only work, and your personal computer for only play. Even better if you can have them in different rooms. Start training yourself to associate one context with work, and one context with not-work. When you sit down in the work context, it's time to work.
- Accountability can feel lessened when no one can see over your shoulder. This can be misleading in the short term because it's easy to get away with it for a while: You can tell people you ran into unexpected difficulties, or you had to spend time on something else, or any number of excuses that work in the short term. Over the long term, the productivity difference starts to show up in your output relative to peers, so avoid falling into this trap. If your company isn't big on short-term accountability, give yourself some daily accountability. A good practice would be to write a short message to your team's Slack channel with what you're going to be working on for the day. At the end of the day, write a short summary of what you accomplished. Once this is routine and public (within your team) you will feel some of the same accountability you did when your team was sitting in the same room and could see you working (or not).
- Offices provide a lot of social exposure that we take for granted. Slack and Zoom can't fully replace it. Make sure you get out of the house and see other people routinely, even if it's just walking around the neighborhood. Simply seeing other, real human beings goes a long way.
- Track your time. Entering the office in the morning and leaving in the evening are natural delineators for your work day. Try to have some similar start and end times at home. Consider using something like RescueTime so you can see where your time is going during the day.