31–40 of 121 posts
That said a 1 or 2 week deadline is much better than the 6 or 12 month deadlines you easily get otherwise. If management needs to have deadlines, shorter ones are less damaging.
I believe the original idea was that there would be plenty of downtime where the team would study the problem and think about the best way to attack it. Then when there was a solid plan, the team would sprint to execute it before returning to thinking carefully about the next issue.
Breaking up work in manageable chunks absolutely makes sense. It makes it easier to monitor progress as a manager, and gives a sense of achievement for a developer. However, the rest of Agile deserves a special circle in hell.
> Breaking up work in manageable chunks absolutely makes sense. But this isn't unique to agile. it's basically how all objectives since the 50's have been organised.
> Interruptions and unforeseen tasks will occur.
That's certainly the case in my current job. Since the product is used for commercial projects, bugs and smaller problems crop up and need to be addressed, usually with priority. And my colleagues regularly need support because they messed something up. It takes a lot of time to make a product fool-proof, and it's nearly impossible to plan.
So I'm in favor of incremental tasks in a larger design. Setting artificial goals and deadlines, which often won't be met, is only a source of frustration, not progress. But getting a larger design done in this way really requires that one person has the oversight.
> Inability to handle reality. Interruptions and unforeseen tasks will occur. The database may malfunction, revealing an architectural issue requiring immediate attention.
These both ring very true in my ear based on 3 years of agile dev at FAANG, less so from the 1 year at a startup. Neither were issues at the other FAANG company I’ve worked for, where devs were given more independence and trusted to deliver when they could.
I think sprints are a useful tool when you’re trying to hit tight deadlines with a group of devs working in parallel. However, I’m not a fan in general.
When I first started coding professionally, I thought sprints were stupid. We've got a backlog that will easily take us a year to complete. Why bother with organizing them into 2-week sections? Why not just finish a ticket, take the next one off the pile, and start working? Over time, I learned that time-boxing your work creates short-term goals, a slight sense of urgency, and some accountability. Otherwise, it's eas…
Isn't the task itself time boxed by the points you assign to the story? > "It is a 2 point story, why have you taken three weeks to complete it?"
Also gotta stop the negative bias. People will want to complain easily if your 2 point story takes you three weeks, but no one will be singing praises if your 5 or 8 point story is done in a day.
The most important part of making it work is to have the team manage the process instead of some external scrum master, and to have frequent retros and adjust the process as needed.
When I first started coding professionally, I thought sprints were stupid. We've got a backlog that will easily take us a year to complete. Why bother with organizing them into 2-week sections? Why not just finish a ticket, take the next one off the pile, and start working? Over time, I learned that time-boxing your work creates short-term goals, a slight sense of urgency, and some accountability. Otherwise, it's eas…
Isn't the task itself time boxed by the points you assign to the story? > "It is a 2 point story, why have you taken three weeks to complete it?"
I don't know why I made that assumption.
1. The sprint goal is not a contract. The mental and physical well being of the developers always takes precedence over the sprint goal. The sprint goal is merely a guidance.
2. Not completing all stories at the end of the sprint should not make you feel bad. A sprint is always filled using estimates which never will be correct, and are often way to ambitious and not considering severe issues.
3. Retrospective meetings should primarily allow developers to say how they could work better. It's not an occasion for the the product owner or the Scrum Master to belittle developers for mistakes and missed goals.