> there have been many times where I've worked on a task or a set or related tasks for weeks or months, simply because the tasks required a lot of forethought and careful planning.
The idea of standups and breaking down work into chunks that fit in a short sprint is to avoid this sort of situation where somebody is off on their own and not getting feedback.
I find that people are overly optimistic about their chances of getting a task completed in the promised time frame. If something is expected to take five days, I'll hear every day that it's going well, right up to the last day, then all of a sudden it's not going to be done. The more granular the task is, the easier it is to deal with slippage because you get to know about that slippage sooner.
A task should be something that can be done independently by one person. Sometimes you have a big chunk of work that's tightly coupled and can take months to implement, how do you best track that?
In my experience what happens is one of three things:
(a) You try and bring multiple people into that feature and it turns into a clusterfuck of awful merge conflicts and hours upon hours wasted on co-ordination instead of building
(b) You track it as a lot of tasks (~30-50), and whoever is working on it spends half their day fielding questions like "Can I pick up that task for you?" or "why are all the highest priority tasks assigned to the same person?"
(c) You track it as one or a small number of tasks (~2-5), and whoever is working on it has the problem GP mentioned with stand-ups, where they don't have anything granular enough to report and end up looking like an incompetent tool.
I've experienced all 3 and they all suck. I'm not convinced that option (c) isn't the furthest down the right track. Option (a) can be a horror show and probably one of the quickest ways to lose a good dev, option (b) can work but it's dependent on a manager that understands the work and isn't going to lambast the dev for blocking up the backlog with self-assigned tasks. Option (c) just relies on adjusting or removing stand-ups to not focus so heavy on day-to-day progress.
- Usually, for large chunks of work, you want to bring in more people. Both because they tend to involve several modules or several layers of the stack, and very few people are equally skilled in every part of the codebase. But also because there will most probably be design decisions and tradeoffs along the way to discuss. Coordinate who is working on which parts of the codebase at any given time.
- I'd avoid excessive preplanning. But I'd make tasks to make explicit the general plan and the interdependencies. E.g. create new server API, then refactor client, then remove old server API.
- Don't be too concerned with showing progress in stand-ups. Feeling like you need to do this to justify yourself is a team process smell. Abandon them if they bring no value, e.g. if you have a de facto three people subteam who is coordinating all the time anyway.
Oh for sure, I'm not saying not to involve other people, just that the actual implementation for some things is most efficient if it falls to one person.
I struggle to think of an example where I'd ever let somebody go off and work on something for months. I can't think of how they would be successful, let alone take on the risk that they quit or get hit by a bus and nobody can continue the work.
It really depends on what kind of software you're building. A large new CRUD feature (which is what most of us are building 95% of the time) can easily be split among many people. But a complex data visualisation, or a novel algorithm, can easily take a month or two and isn't easily split amongst the team, even if you have multiple members with the expertise to implement it.
EDIT: Also, just because someone is working on a siloed task doesn't mean that nobody else can pick up where they left off. For that to be true you have to assume they document nothing and code like an idiot (which is unfortunately probably pretty common).
This type of work is highly atypical. All the scrum ceremonies were designed around fast feedback, if you can't fit it into the work you do then using anything agile-related is not going to work.
The idea of standups and breaking down work into chunks that fit in a short sprint is to avoid this sort of situation where somebody is off on their own and not getting feedback.
I find that people are overly optimistic about their chances of getting a task completed in the promised time frame. If something is expected to take five days, I'll hear every day that it's going well, right up to the last day, then all of a sudden it's not going to be done. The more granular the task is, the easier it is to deal with slippage because you get to know about that slippage sooner.