[br3w5]

I think the OP's mindset is flawed and perhaps had some bad experiences/coaches with Scrum and possibly only one go at it?

I'm not sure why anyone would say "Scrum doesn't want to solve this". When I've worked with teams new to Scrum and the question "how does this fit into Scrum?" comes up, I'll discuss with the team and we come to a pragmatic agreement that is right for the situation and context. Similar to TDD, I think it's great but it's not always the right approach in 100% of situations; adapt it to your needs.

All methodologies have their flaws and Scrum can sometimes frustrate me (I'm not a purist) but I definitely prefer it to waterfall. Mature teams take the bits that work for them and improve on the ones that don't. It seems the OP is taking the methodology too literally which implies a lack of experience in trying to apply it.

I've tried (and failed) to get a team to work on a feature as a team, refactoring as they go. This didn't work, not because of the methodology, but because the team just couldn't get their heads round it. We decided this was fine and worked on UX a sprint ahead (and built this into the definition of ready). A methodology should not have to cater for every personality and set of skills - that's down to you as a team to figure that out.

Teams at first won't organise themselves but once they start taking true accountability for their work (and not keep looking to a project manager for direction) I've seen teams start to get more efficient and more motivated because they get to take control of their work and define the process.

[jghn]

"but I definitely prefer it to waterfall"

I pretty sure you're not doing this here, but there's a lot of options outside of the set of Waterfall & Scrum. All too often when scrum is debated it's often set up in the "well, at least it's better than waterfall!" argument. Great, that might be the case - I'd rather a kick in the ass than the nuts but really I'd prefer neither :)

"the methodology too literally"

As the saying goes, "how big is your but" - because everyone does scrum-but. I'm not a fan of scrum in general, but once the but becomes large enough "scrum" and i can be friends again. The purists drive me bonkers though.

[derefr]

I think when most people talk about agile, or any specific instantiation of it, all they mean is "we're going to not-do-waterfall, and then intuit the rest, while attaching names from some methodology book to whatever results."

[jghn]

True, and admittedly "scrum" has become the "kleenex" and "xerox" of the agile world. Fair point.

[br3w5]

I think my statement about waterfall is misplaced - really I mean the benefits of scrum in my experience outweigh the negatives but I can't say the same for waterfall.

I'm well aware of alternatives to Scrum and if I could choose I would prefer a kanban approach supporting continuous delivery/deployment; rather than be bound by all the constraints of the scrum ceremonies and sprint timelines. Hopefully I'll get to put this into practice in the next couple of months with my team.

[kryptiskt]

Waterfall is a 45 year old strawman, born to be a whipping boy: http://jayacarl.blogspot.se/2009/01/waterfall-model-not-what...

I don't know why we are obsessed with that bogey man. While there are some places that use waterfall, sometimes with good reason (things where the spec is critical), the most common state of unenlightened software engineering certainly isn't to have big design up front. It's to have design on a napkin and lousy communication with stakeholders, more wild west than waterfall.