| The main problem I see with scrum (and agile generally) is that it has wandered away from where it was originally conceived into places it just doesn’t work. If you are building a product with a very close partnership to the end user with a small, experienced team who share a both a common view of the world and a common definition of success then scrum can work very well. Although, ANY methodology can work well in that environment. The further away from that ideal the less successful scrum will be. Do you have a team of mixed ability? Scrum will have trouble because you are supposed to view everyone’s opinion as equally valid (but that new grad just doesn’t know as much as the grizzled veteran and scrum doesn’t accommodate mentorship). Are you one or two steps removed from the end user? Then you are going to have problems because scrum demands a tight feedback loop with your user so if the “product owner” needs to launch a three month “customer survey” to answer every question you have many sprints without any meaningful feedback. The fundamental truth is you can dictate what is built, or you can dictate when you want it. You can’t do both (because any meaningful software is by definition novel). Scrum tries to say “deliver every sprint” without being opinionated about what get’s delivered. That can work with a tight feedback loop with the end user, but invariably product managers, sales, and business strategists get involved and they all want to be able to promise Things by Dates (“we won’t hold you to the dates, honest”) and that’s where it breaks down. All of this is before you even get into the cargo cult of points poker (the value is in identifying mismatches in shared reality, not in sizing the stories) or stand ups (which only work if you are all trying to deliver One Thing). Finally factor in that early adopters or scrum were actively looking for alternative ways to develop software beyond the “conventional wisdom” of waterfall whereas now everyone views agile/scrum as conventional wisdom and it’s unsurprising that most people have a decidedly subpar experience. |
No, you aren't.
> (but that new grad just doesn’t know as much as the grizzled veteran and scrum doesn’t accommodate mentorship).
Scrum doesn't explicitly address mentorship, but neither does it “not support” it.
> All of this is before you even get into the cargo cult of points poker
“Points poker” is not (in fact, neither stories, nor story points, nor using planning poker to assess story points are) part of Scrum.
Its a set of independent practices that are frequently used with various development methods.
> stand ups (which only work if you are all trying to deliver One Thing).
If you aren't trying to deliver the One Thing, you aren't part of the same team in Scrum. People being part of multiple Scrum teams is accommodated by Scrum, and you can't have a coherent Sprint Goal unless each Scrum team has a sufficiently narrow focus; equating Scrum team with exclusive reporting heirarchies is not part of Scrum