Ask HN: How to incentivize my Eng team to update tasks after daily standups?
I have team of 10 Engineers and we do daily standups. However no one keeps their tasks updated and my PM struggles to assess project progress. I become the broker between PM and my team. Why is it so hard for engineers to open their tasks and write one sentence about the progress?
There is a lot of busy work that Engineers have to do. My experience is that engineers are usually over-utilized so they naturally deprioritize things that aren't mission critical or aren't providing them value. In that regard, I think you need to prove value of task tracking to the team.
The way our PM did this was that he manually updated all of the tasks himself. Once the task tracking system started working for the engineers--and this could take months--they started happily updating it.
Another strategy our PM employed was organizing stand-up around the task board. He'd specifically ask for feedback on tasks rather than round-robin asking for updates. He said the phrase, "if it isn't a task it isn't work," while also happily creating tasks for any outstanding activities unaccounted for at the end of stand-up.
So I'd recommend this strategy of the PM making task tracking work for the team before having the team make task tracking work for the PM.
PM doesnt attend standups most of the time. There is a "scrum master" assigned but that is not a real role, its just round robin and ever engineer gets to do the role. The scrum master just calls out people's names (team is in person + online) and asks them to provide updates. No one, not including the scrum master updates anything. Though I am up to speed, but PM is not and this becomes challenging for them (and sometimes for me too if I am unable to attend standups)
Sounds like your process is a little broken and dogmatic and useless, which can happen if people follow Agile blindly. Can you tweak it to make it more useful for your team? Encourage what works and drop what doesn't.
We follow the canonical agile, or we think we do. Backlog grooming->Sprint planning->Standups->Retros->Backlog grooming. What else is missing in this process? Seems like this problem of engineers not updating their tasks is very unique to my team maybe? Could this be solved by process, or incentives, or tools?
Canonical and capital-A Agile never, ever works in my (admittedly limited) experience. Part of the original Agile philosophy was "people over process", but when you get overly dogmatic about it and hire consultants etc. and try to enforce every little ceremony, those thoughtful guidelines then become corrupted into a useless bureaucracy that prioritizes process above all else, even when the process is no longer working or serving the team.
Forget the official methodology, talk to your team and tell them you realize the process isn't working and ask them what would be a good way to give the stakeholders the updates they need without imposing undue work on the ICs.
Sometimes a simple and well-tolerated kanban that people update as needed is more effective than rigid daily rituals hated by everyone.
Focus more on what is important to them.
They are delivering the work, you need to understand why they don't have time to update tasks and why they don't see it as a priority.
Your goal should be to understand their position, not force them to do something that they see as low priority.
Successful projects don't come from engineers being forced to do Agile ceremonies.
Makes sense. I understand its not priority for engineers because they like codinf so much. But then I need to provide status to my PM and my stakeholders (incl my manager) too. It becomes hard for the rest of us. I guess thats why some companies hire a dedicated person to do this work -> ask every engineer about their task -> update task -> repeat -> get $120K salary. The other way I am thinking is to ask the "scrum master" to open every one's tasks one by one, and update it syncronously. Or ask every engineer to update it before they are done talking for their status update.
It's not that "we like coding so much", it's that we hate pointless busywork. If you need a status update on my project, that's something I can provide in a sentence or two over Slack or in a PR or a Kanban. Progress usually looks something like "Partial fix for #4278. Almost there.", which can be auto linked to ticket 4278. The PM should be able to at least read commits and PRs at a general level and ask specific people for more details when necessary, not drag everyone into meetings all the time just to hear everyone else's details.
If you're going to make me sit through a daily meeting where everyone goes in a circle saying all that, and most of it is "Still the same as yesterday", I'm going to resent it for wasting time.
I mean, stand-ups are whatever, 15 minutes isn't the end of the world. It's the additional combination of all the other ceremonies and endless meetings that cumulatively add up to way too much wasted time and interruption of flow.
Agile demands way too much time and breaks of focus just to provide basic details. It results in situations where X team members are waiting and twiddling their thumbs listening to the updates from X-1 other team members just so that one manager can learn what the team is up to. Not just in stand-up but every other planning ceremony and retro.
Simple async updates that happen when progress actually changes are much less demanding. Perhaps that's worth a shot?
You can force people to adopt Agile with enough pressure, but that won't magically improve transparency, productivity, or morale. It's a false promise that really just teaches engineers to optimize for the aesthetics of work (overestimating points and difficulty, shuffling tickets around, coming up with BS insights for retros, etc.) to LOOK more productive instead of actually doing the work.
The code is the work. The pull request is the workface. Add automation to comment on stories that "a branch was pushed," or "a pull request was created." Then you know someone is waiting to review or it's still in progress.
A Jira query is easy enough to set up for "stories that have changed status in the past day." Check daily.
If stories aren't moving, maybe team is collaborating around current issues. That's for certain if a new deployment hasn't made it into staging.