(Sigh) This is just a religious pronouncement in a religious war. There are many processes out there - not just sprint, kanban, water fall, or "no process". Pick the process that works for your team.
As an engineer and an engineering manager I have worked in strictly controlled water fall, "no process", well structured sprints, kanban, and scrumban. They all have their pros and their cons, their costs and their benefits. It's a question of what works for the team.
Personally, 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. Sprints with a heavy planning component work very well for that. But that's just my preference.
Teams should decide what method they're going to use and commit to making it work. They should also be open to recognizing when it isn't working for one reason or another and be willing to try something different occasionally.
The only piece of process I will always insist on is some sort of regular check in where we can introspect about the process and determine what aspects of it are and aren't working.
> 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.
As an engineer and an engineering manager I have worked in strictly controlled water fall, "no process", well structured sprints, kanban, and scrumban. They all have their pros and their cons, their costs and their benefits. It's a question of what works for the team.
Personally, 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. Sprints with a heavy planning component work very well for that. But that's just my preference.
Teams should decide what method they're going to use and commit to making it work. They should also be open to recognizing when it isn't working for one reason or another and be willing to try something different occasionally.
The only piece of process I will always insist on is some sort of regular check in where we can introspect about the process and determine what aspects of it are and aren't working.