Why Scrum is fundamentally broken (but we still use it)(joostdevblog.blogspot.nl)
joostdevblog.blogspot.nl
Why Scrum is fundamentally broken (but we still use it)
http://joostdevblog.blogspot.nl/2014/03/why-scrum-is-fundamentally-broken-but.html
7 comments
The author has a very literal notion of "shippable". Shippable could mean to a beta group. It could mean to the public. It could mean that the feature is "done" but not turned on or it's hidden behind a feature flag.
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.
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.
Agreed. His argument is essentially that you can't meet deadlines with Scrum, because you must always be in a 'shippable' state at the end of each sprint.
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.
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.
Why bother redefining "shippable" just so that you can remain buzzword compliant?
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.
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.
Sounds like multiple, official, scrum trainers told him he needed a literal shippable product at the end of each sprint.
Shipping dates are therefore always met according to Scrum: just stop developing at the deadline and release the product in whatever state it was in at the end of the last Sprint.
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".
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".
It sounds like he is saying that Scrum is not compatible with platform specifications because those are too stringent… From my experience, those are not very appropriate as goal posts, but they don’t make scrum unusable; there is just a secondary list of goals between Playable (locally) and Shippable, in addition to game specification.
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.
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.
The main principle behind the potentially shippable product increment is linked to the concept of always prioritising the highest business value stories, and in particular vertical slicing of functionality so that its implemented top to bottom.
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.
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.
You don't have to create something ship-able between each sprint, it just has to be demo-able.
There's nothing more annoying than a blog that commandeers swipe navigation.
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.