> I developed a preference for scrum style sprints as both an engineer and as a manager, because I prefer to work collaboratively where everyone knows what everyone else is working on and everyone gets a chance to have a say
Are sprints necessary for knowing what other people are working on, and for having a say? I thought sprints are only tangential there.
No, you can absolutely achieve that goal using other processes. However, in my experience I've found sprints to be the way that works best for the teams I've been on and those I've lead. But it all depends on the team and how they structure the sprints.
In the case of the teams I've been on and lead, the sprint is structured with a planning meeting at the beginning of the sprint in which everyone goes over each story. Stories with enough complexity to warrant it have an execution plan attached (written during a SPIKE in a previous sprint) that allow the whole team to collaborate on the execution - everyone can go over the plan together, agree on the approach, poke any holes in it, etc. And this gives everyone a much clearer picture of what's being worked on.
In my experience with Kanban, it's much easier for developers to lose track of the work of the whole team. They focus on their current task, and the task they plan to pick up next. Being able to see the work on the board isn't the same thing as actually knowing and understanding it. Sprint planning lends itself much more to that.
That isn't to say you couldn't run an equally collaborative Kanban process with some work. My experience was just that it was much harder to achieve that level of collaboration with Kanban. That's through several iterations on different teams. Not impossible, just harder. And when there's a ton going on and you're going fast, you generally want your process to make it easier to work the way you want to work. IE. You don't want to have to work extra hard to make your process collaborative, you want your process to make it so that it's hard not to be collaborative.
But again, this was just my experience on a few teams and what works for those teams.
Are you asking because you read dbingham as saying sprints were a requirement for that? I didn't interpret 'necessary' in there at all- but rather that method of organizing work tended to produce that type of result.
My question still stands - how are they related to each other? I can see what others are working on by looking at the issue board or just asking. And I haven't experienced that sprints contribute to devs having a say in anything.
Are sprints necessary for knowing what other people are working on, and for having a say? I thought sprints are only tangential there.