A rant on Scrum
Came across an article in a newsletter subscription. What would you all have to say about this one? I do agree that a potentially shippable increment isn't possible in most of real world sprints. However it should be at least attempted as incremental value through small and testable work items.
I disagree with most of what is said in this article because it completely skips the Scrum values and three pillars. It only focuses on the events (infamously known as meetings).
Having said that I am still curious to hear from you all what you think about what's said here. And for that matter what Gunther Verheyen, Jeff Sutherland, Ken Shawaber would say on this.
Unfortunately, the article that you linked to is behind a registration (maybe a paywall, I'm not sure), so I can't read it for myself. However, I would disagree that a "potentially shippable increment isn't possible in most of real world sprints". It may require a shift in thinking to come up with ways to make work demonstrable and keep a fully integrated increment shippable, but it's definitely possible to achieve that. If a team can't, one of their first objectives should be to get there. Then, they will be able to realize other benefits.
Sorry this one
Please ignore the earlier link. Wish there was a way to edit the post from a mobile device.
It is still behind a registration.
I agree with @Thomas Owens. I have worked with MANY teams that consistently produce a potentially releasable increment at the end of every sprint. It requires a different way of thinking. Such as you can't build a backend over 2-3 sprints and then build the frontend for it over more sprints. You have to build both parts in small increments over a succession of many sprints. Each piece is functional but not worthy of release. That is why they are called potentially releasable.
I read through the article, but I must admit the writing style was rather laborious. It didn't feel like a well structured critique of Scrum, but rather a rambling list of complaints; including objections to terminology, Scrum's inability to be an off-the-shelf solution, and poor implementation choices, often based on false assumptions of Scrum, either by the author (or those he's come across).
There can be legitimate criticisms of Scrum, and I felt with a better writing style, the author might have been able to express them better, such as whether Scrum encourages excessive batching, or whether the way it has been widely misused and misunderstood can be detrimental in environments where agile product development is not already well understood; but I saw no evidence that the author wanted to properly critique Scrum.
It seemed more like a hatchet job, aimed at promoting his own methodology; but perhaps it was more innocent, and these were just the inadvertent complaints of someone who'd missed the point.
Most disappointing was that the author did not touch on empiricism, or how Scrum simultaneously relies on and enables empirical process control.
For me, that's the most important aspect of Scrum, because if Scrum is implemented well, and begins to cause more harm than good, it should become apparent to everyone involved, and a better way of working can be considered.
I don't think it matters whether an organization is using Agile or Waterfall to keep itself organized. What is important is that if Company A's product takes a year to get to the customer, and Company B's product gets to the customer in six months, who do you think will stay in business for the long term? Focus on the product and on creating value for the customer.
And here's a much more in-depth response to that specific article:
https://www.scrum.org/resources/blog/scrums-nature-it-tool-it-not-about…