I think a mixture. Coining the term “Ban Scrum”. Which is a mixture of KANBAN and scrum sprints. Where the sprint is not over until an identified set of tasks/stories are completed. The truth about software development is, it takes as long as it takes. But you don’t have infinite time. So digest what needs done, carve up/reduce into the smallest workable step/task, group like things into sprints. Work those sprints until complete. This also allows for larger teams to work more sprints concurrently by dividing the dev teams up into smaller unit teams. Then having a single KANBAN board for management to watch progress. While also allowing for continuous development and rolling releases, eliminating the artificial deadline of the traditional scrum sprint and resulting crunch of code reviews a day or so before the end of sprint cycle.<p>Ritual meetings are similar, but there is never a end of sprint meeting/next sprint planning session. Rather a weekly sync up to talk about what’s working and what’s not, what can we do better. Then weekly backlog grooming to identify and group future sprints to get them ready to be started, when it is natural to start that work. Then of course daily standup to communicate roadblocks to managers so they are aware and can do their job to unblock the road, and also to promote general awareness to of other team members of what each other are doing.
Not a developer here. I work mainly as a translator, and I work alone, so YMMV.
Kanban works best for me. I have a self-hosted Kanboard instance (<a href="https://kanboard.org" rel="nofollow">https://kanboard.org</a>).
However, sometimes even that is difficult due to the hectic pace of work when business is abundant.