Adam Gonnerman

It's one thing when agile coaches pipe up with "that's not Scrum," and quite another when accusations of "fake Agile" are thrown around. I find the former irksome, but at least they have a leg to stand on with the 'End Note' of The Scrum Guide in their corner: "Scrum is free and offered in this Guide. Scrum’s roles, events, artifacts, and rules are immutable and although implementing only parts of Scrum is possible, the result is not Scrum . Scrum exists only in its entirety and functions well as a container for other techniques, methodologies, and practices." (emphasis mine) This is why I've taken to calling any more pragmatic approach 'Notscrum.' After all, if they insist that Scrum is 'immutable' ( like Plato's heavenly perfections ), then clearly what I introduce to teams and use to coach them is a more mutable creature, one that adapts to situations to achieve the dream of Agile. "We are uncovering better

"You can't be agile when you're knee-deep in mud."  -  Martin Fowler One of many mistaken ideas I held when I first got into Agile project management was that over time a Scrum team should be able to increase its overall velocity. The scenario I had in mind assumed that the team was stable and had become consistent on forecasting story point values (commit vs complete). The problem begins right there, with those two assumptions, and goes much further. There are ways to improve team velocity, but there are limits. First, although a team may be fortunate in remaining stable over a period of months or years, this is not something I've found to be the case very often. Team members come and go, sometimes because they're reassigned and other times because people naturally come and go from the company. One often overlooked source of instability is out-of-office time, whether through maternity/paternity leave, vacations, or illness. Capacity planning can be challenged

"The Product Owner is one person, not a committee. The Product Owner may represent the desires of a committee in the Product Backlog, but those wanting to change a Product Backlog item’s priority must address the Product Owner." - The Scrum Guide There are a lot of ways in which my approach to Scrum differs from what's in the official guide, and since that document refers to Scrum as 'immutable,' let's just call what I do 'Notscrum™.' In Scrum, there is only one product owner per team. That person is the sole person responsible for the product backlog, and the person who advocates for the work to be done. In Notscrum there is one product owner, but there can be multiple deputy product owners. Here's how it works. When my program at Viacom was first forming I met with the then-director of the Library & Archive group and learned that while he set the priorities on work done, the archivists were organized in three distinct areas with a team lead