[chillingeffect]

An eager beaver at one of my client's is introducing Agile as a "Waterfall silver bullet."

I see right away one Agile defect: It prefers near-term "user story success" over long-term investments like creating debuggable architecture.

Why spend time now making things easier for the rest of the cycle if it's not a priority in this iteration?

Why write "gdb" when "gcc with printfs" will work fine, even if it simply requires more sprints?

[dragonwriter]

> I see right away one Agile defect: It prefers near-term "user story success" over long-term investments like creating debuggable architecture.

Neither the Agile Manifesto nor even the far more specific Scrum Guide even refers to user stories.

A particular organization using Scrum may decide that architecture-related concerns are not important in the definition of "done" for items in their product backlog, and focus only on "user story success", but, to the extent that that's a problem, that's not a Scrum (and much less, Agile) problem, its an organization problem.

Agile is about what concerns you favor in figuring out how to get work done, Scrum is about how a team gets work done and defines the work it is to do within the framework provided by the wider organization, but the specific definition of quality standards for work is not directly addresses by either.

> Why spend time now making things easier for the rest of the cycle if it's not a priority in this iteration?

Why wouldn't an organization have maintaining (or improving) the overall architectural standards of the work a priority for every iteration -- in Scrum terms, part of the Sprint Goal -- unless there is a conscious decision to take on technical debt to meet some other goal? Agile, or even Scrum, doesn't tell you what goals to set, and you shouldn't blame them for you choosing to set the wrong goals.

[lostcolony]

If you're doing SCRUM, hopefully, when planning, you're building in slack for the devs already. Your sprint commitments should always be conservative. If something ends up taking more time than you planned, then, it'll just take up some of that slack.

With that slack, then, when things go right, you have time for dev priority tasks. You hit your sprint commitments two days before the sprint ends? Great! Time to work on some of those long term investments.

You can also scope stories based on dev priorities. You want to add a feature to part of the code that is in need of refactoring? Scope the story to include that refactoring.

Etc.

If using Kanban or something, it's a bit harder; you can easily take time for dev tasks (since you're not making commitments), but finding the right balance of taking them on but still getting feature work done is harder.