[paskozdilar]

> from a SWE perspective on any kind of Agile/Scrum team I think the expectation is usually that you pick up another task if you finish early and there's still time during a sprint for example.

This is true, assuming that:

1. the whole team has approximately equal skill

2. the system is uniform and well-documented

3. the people actually give a shit about the product

If any of these assumptions are not met, then the expectation is naive.

[fatnoah]

I can't think of any environment that I've been in where this is true. I think the closest I've been was as part of a team of three people where each of us could really handle any task in the codebase. It was also true that there were things that we each cared far more about as individuals, so, in spite of comparable skills, we tended to gravitate to specific stories, anyway.

As a manager, I have every expectation that we won't be doing scrum exactly by the book, but that's totally fine. I'm more concerned about (reasonably) consistently reproducible levels of productivity, not squeezing every point out of a sprint. If there's slack time, great. That seems to be when people are most likely to contribute new stories, learn something new, etc. Besides, rigidly following scrum feels anti-Agile, anyway. People and interactions over tools and processes.

[laserlight]

Picking up another task doesn’t mean that it has to be finished. If one lacks skill, they can train. If documentation is missing, one can document whatever they learn. The last one is difficult to address, but not impossible. If team members don’t give a shit about the product, I bet they can still find something they give a shit about that also contributes to the product.

[paskozdilar]

You make a good point. I guess as long as the people are passionate, the first two issues can be, over time, worked through. I guess the tarpit is that the "time" can be really long, especially for (skill-wise) heterogeneous team working on large undocumented projects.