ScrumButs and Modifying Scrum
ScrumButs are reasons why teams can’t take full advantage of Scrum to solve their problems and realize the full benefits of product development using Scrum. Every Scrum role, rule, and timebox is designed to provide the desired benefits and address predictable recurring problems. ScrumButs mean that Scrum has exposed a dysfunction that is contributing to the problem, but is too hard to fix. A ScrumBut retains the problem while modifying Scrum to make it invisible so that the dysfunction is no longer a thorn in the side of the team.
A ScrumBut has a particular syntax: (ScrumBut)(Reason)(Workaround)
"(We use Scrum, but) (having a Daily Scrum every day is too much overhead,) (so we only have one per week.)"
"(We use Scrum, but) (Retrospectives are a waste of time,) (so we don't do them.)"
"(We use Scrum, but) (we can't build a piece of functionality in a month,) (so our Sprints are 6 weeks long.)"
"(We use Scrum, but) (sometimes our managers give us special tasks,) (so we don't always have time to meet our definition of done.)"
Sometimes organizations make short term changes to Scrum to give them time to correct deficiencies. For example, "done" may not initially include regression and performance testing because it will take several months to develop automated testing. For these months, transparency is compromised, but restored as quickly as possible.