What is your preferred Software Development Process (SDP) and why?

A couple others posted things along the lines of: "I don't care what the process is." But, you have to have *some* process, either a name-brand one or one you invented. Scrum and Kanban are solutions to the same problem - how to let developers focus on a small number of things at a time while also allowing for frequent course correction - but with different trade-offs. I like Scrum for its ability to rally the whole team around something: we're all going to focus on a set of things together for the next two weeks, we'll deliver some software, and then we'll course correct at the end of the two weeks based on what we learn. What I've observed though is that lots of software teams end up with so much overflow, that it doesn't work well in practice. If 30% or more of your work carriers over, then you can't effectively re-prioritize, and you've lost some of the advantages. Kanban accepts a different trade-off: we don't worry about getting the whole team on a fixed cadence, since we have a constant stream of work, and we use work-in-progress limits to allow engineers to focus, but that means there isn't necessarily a time when a whole group of people can shift focus all at once. When done well, a process won't fix a broken team, but what it will do is help create transparency into how things are going. *With the right management*, that transparency can then lead to positive changes. To talk through an example: I was on a team once where we had just an awful sprint. But we stuck to the process, and we did a demo at the end of the sprint, and it was embarrassing. Other stakeholders left the room, leaving the development team and our CTO. A different sort of manager would have started finger-pointing, blaming, and so on, but our CTO lead a frank, open, non-accusatory conversation about what we could do better. The demo two weeks later was one of the smoothest I've ever done, and we delivered something like 19 out of the 20 stories on our sprint board. It's worth mentioning that just because someone says "we're doing Scrum" or "we're doing Kanban," it doesn't mean they are. Not all Agile consultants are equally knowledgable about what building software is actually like or how to communicate the ideas. So there's a decent amount of people saying they don't like whatever process, mostly because their local implementation misses some of the point of the process. Finally, there are a few number of teams that say "we don't really need a process." If you observe what these teams actually do, they have a process, it's just implicit, hard for people outside the team and newcomers to understand, and very often ends up re-discovering lessons other people learned (but in a more expensive way).