You don't need Scrum, you just need to do Kanban right (2022)
Scrum is meant to protect the team from changing requirements mid-work and it&#x27;s a good way to work when you have a &quot;client&quot; that requires &quot;features&quot; to a product.<p>There is a well-defined standard process for them to add things to the backlog and there is a written down definition in which state items in the backlog have to be in so that they get picked up for the next sprint. If the team works with just one client&#x2F;product, the client can prioritise the backlog.<p>During the sprint they can&#x27;t give any input or request &quot;just this one quick feature&quot;. The work is locked during the sprint. If they REALLY want something, the Agile Manifesto says to drop and delete all ongoing work and start a new sprint from scratch. Exactly zero clients have agreed to that - they really weren&#x27;t in that much of a hurry with the feature.<p>After the sprint the client gets a demo of what the team achieved. An actual demo with the actual product. Not a powerpoint presentation of an ideal state or a video done in a demo environment. At this point the client can provide feedback and new features and we GOTO 10.<p>Usually a single member needs to be defined as a firefighter who takes on bugs and production issues that can&#x27;t wait for the next sprint, but we don&#x27;t tell that to the client. If there is no urgent work, they work on the sprint tasks as normal.<p>--<p>Kanban on the other hand works if the tasks have no dependencies with each other, like building maintenance or IT&#x2F;DevOps type stuff.<p>&quot;Install new laptop for Karen with standard package&quot; doesn&#x27;t require a sprint, anyone on the team can do it. Or &quot;Set up AWS account with ECS for team B&quot;