I’m slightly concerned that we’re hijacking @SamFitzpatrick’s thread and should keep this discussion for later but it’s a bit entangled in the rigging so:
You can’t ‘do’ a set of principles. I think agile always turns into process, though not necessarily procedure. Otherwise, you’re just making stuff up as you go.
My main point was that there is no clear definition between what is a bug or a required feature in agile, without a definition of done, because there is no fixed scope. A bug exists if the user-story does not meet the definition of done. The questioner clarified that his question was ‘what happens if you find a bug after the story is declared done?’ The answer is that “you can’t”. If you find it later then, in Warerfall terminology, ‘it wasn’t in the spec’ so should go on the backlog, as a new story/task with new tests/DoD. The bug was ‘in the spec’, so the customer is asking for something that wasn’t agreed to. Effectively, the tests/dod specify the scope of a user-story.
In Scrum, the Product Owner sets priorities so we may not fix all of the bugs. Agile means to move and change direction fast. It doesn’t mean you won’t drop anything or that the PO will let you collect the injured.
Yes ‘techies’ was limiting, to a set of people who may be both a subset and a superset of developers. I was talking about people who care more about the technology than the business problem or its solution, the To-Be process, whether implemented in software procedures or humans.ñ