Purists would realize that Scrum was defined to be a self reflecting, self improving system. Scrum allows people to alter scrum to meet their needs.
> Scrum deliberately asks the team not to look too far ahead
This is not true. The product owner can put as much stuff on the backlog as they like and the team should know about it. Scrum does ask the team to not spend a lot of time estimating out stories that are months down the road (so very loose estimates are ok).
> Scrum forces that the plan cannot change during the Sprint. This way they know where they stand during the Sprint.
This is true but not totally true. Scrum requires the product owner to "stand back" during a sprint. But, at any time, the product owner can declare the sprint un-productive and it restarts. How does the team know they aren't adding value if the product owner can't stop the sprint?
> For a game to be "potentially shippable" after every Sprint (as Scrum requires) the certification requirements
See above where scrum allows you to alter the "rules" of scrum to meet the needs of the users. Scrum is not written in stone.
Also, you are supposed to have retrospectives after each sprint to improve. This sounds like a discussion that should have happened with the OP's team at a retrospective.
I'd argue that if you can't meet deadlines with scrum, there's no way you'd meet them without it. His definition of 'shippable' is very narrow--like you said, just because it doesn't meet console certifications doesn't mean that it's not "doing scrum".
I wouldn't put the app I've got after the first dev sprint on the app store, either. It's not done.
Extract the good ideas, and leave dogmatic adherence to the charlatans selling buzzwords. If non-rigid use of a methodology leads to unintentionally missing out on a benefit of the methodology, whoever is selling the methodology failed to articulate that benefit.
The author perpetuates the myth that scrum is incompatible with businesses that have hard real-world deadlines. This is not true. Nothing in scrum requires you to blindly plow forward working through an un-altered backlog one week at a time until you either miss a big deadline or release a half-baked product. All scrum requires is that when adjustments are made (like cutting features in the face of an upcoming deadline), they are made according to an orderly process of prioritization that occurs during sprint planning and while grooming the backlog.
What agile buys you is early warning when inconsistent objectives emerge, so you can make adjustments well in advance instead of in a last-minute panic right before the deadline. Sprint-by-sprint demos ensure that you really know where you stand versus your backlog and roadmap. No more, "I think we're about 20% done with that".
Not sure why he calls the first one ‘Potentially shippable’ though, not when he imagines project development with significant artwork drafts that should not be shipped: contradiction is within his own interpretations, there, not incremental methodology.
In the game industry this would generally align with working towards a single level demo, possibly with simple graphics so that its playable and gives the end user an idea of what kind of game it is, and how enjoyable it could be with more work.
Now for a new type of game, or something a little different, this is absolutely the best way to go as you can find out if your belief in this game is supported by interest from those who play the demo before you spend years and huge amounts of money. So the standards you'd need to meet from Microsoft or Sony need to be implemented only when you feel you would like to ship it to the general public.
If used for the next Call of Duty game it may well damage the brand unless it surpasses the standard of the previous game, so whilst it is potentially shippable, it wouldn't be sensible to ship it any further than internal testers until you know its to a high standard.
Scrum is simple to implement but harder to get right, which is why so many groups implement what is defined as "ScrumBut", and when they don't get the suggested benefits blame Scrum rather than their "ScrumBut".
Think of it as being similar to speaking to a Spanish person. Scrum is speaking pure Spanish, and ScrumBut is speaking mostly Spanish and some English as you can't quite master those more complicated parts. If they don't fully understand you can't guarantee its the fault of the Spanish language, but rather its more likely the few English words you've used instead of the possibly mispronounced Spanish ones.
I'm certain there are some teams who have implemented pure Scrum and have not found the suggested benefits, but so many of these posts slagging off Scrum I've read are from people who have adapted Scrum, or haven't implemented it as suggested in books/courses.
I'm certain many of these people will end up slagging off XP, Kanban and every other framework/practice when they don't implement those fully either.
Before any quotes the Agile Manifesto at me, the individuals and interactions part is suggesting that if doing something at a process level that isn't adding any value then you stop doing it as you can achieve the same with less process and more interaction, not stop doing it because you don't like doing it even though its something you should do as it adds value.
