Loading ...
Sorry, an error occurred while loading the content.

41659Re: Technical quality advocator

Expand Messages
  • JackM
    Oct 1, 2009
    • 0 Attachment
      IMHO, this is a really bad attitude. Now let me clarify. I realize in many situations, one can't fix all bugs for whatever reason that's not practical. However, the team needs to agree on their goals for the definition of done. And teams should strive to meet those goals. If it means that you're going to leave all low priority bugs fine, that's your definition fine - BUT you must understand that even small inconspicuous bugs starts to build technical debt into your codebase that in time will drive the team into a corner and will be forced to BEGIN AGAIN.

      That's why it's important that you refactor whenever you can (preferably all the time), You have extensive suites of unit tests, automated functional tests, you pair program, do code reviews etc. If you set the quality bar high it pays off in spades. Short term pain for long term gain.

      Jack
      blog.agilebuddy.com
      twitter.com/agilebuddy (for daily references to Agile articles, blogs, and more)


      --- In scrumdevelopment@yahoogroups.com, "Inanc Gumus" <inanc.gumus@...> wrote:
      >
      > As a SM, I advocate about technical quality standards to the team. But, most of the team members usually resist this kind of actions. They take a more pragmatic attitude for the story goals. They say: "it is good enough for now, if that defect makes the system down, or decrease its performance then we can handle it that moment".
      >
      > What do you think about this? If a team tries to deliver high priority work ASAP by deferring the mediocre technical defects to later; should that work be accepted?
      >
    • Show all 24 messages in this topic