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

41670Re: [scrumdevelopment] Re: Technical quality advocator

Expand Messages
  • Adam Sroka
    Oct 2, 2009
      On Thu, Oct 1, 2009 at 11:54 PM, Inanc Gumus <inanc.gumus@...> wrote:
      > Hello Ron,
      > --- In scrumdevelopment@yahoogroups.com, Ron Jeffries <ronjeffries@...> wrote:
      > > In simple terms, the team has a bad definition of done, or is not
      > > living up to the definition they have.
      > >
      > > The more interesting question is why. What is making them value
      > > shoddy work?
      > >
      > > Ron Jeffries
      > >
      > I asked this to the team, and they said: "delivering something which business puts a very high value is most important". They say, in a future time after the pressure decreases (which i think will never happen), they say they would be more quality-driven.

      One of the things I like about the way that XP describes planning, vs
      the way that Scrum does, is that it acknowledges that planning is a
      game. It is a game because the PO and the team have different concerns
      (rightly.) The PO's primary concerns are business value and business
      risk. The team's primary concerns should be technical risk and

      It sounds like your team is more concerned with pleasing the PO than
      with serving their own interests. Likely because they don't recognize
      that they are responsible for more than just checking stuff off as

      > They don't see the stories as a chance to improve their architectures. Rather, when a story can be accomplished by doing a work-around solution in the system, they do that so. So, they're increasing their defect rates consciously.

      You need to convince them that working this way in unacceptable.
      Introducing defects doesn't serve the PO's interests or theirs. Time
      has to be spent fixing those defects and that time can't be spent
      developing new features. They are "robbing Peter to pay Paul," as the
      cliche goes. It's going to be an uphill battle, but you need to
      convince everyone concerned that quality is in their best interests.

      > Also, the team is trying to learn new knowledge about the technologies which they seem are valuable. This increases the re-work rate because they're doing something wrong at the 1st, 2nd time, and then they're thinking to re-write those parts from the begin again. They're mostly doing minor refactorings (like changing variable/method names etc), not doing something like evolving the architecture step by step.

      It's not an easy thing to do. It's not even easy for those of us who
      have devoted years to learning to do it that way. To be effective at
      it you first have to accept that it is valuable. Then you have to work
      hard at it to make it work. You will fail. You will produce crap which
      you will look back at later and say, "That is crap."

      But, it is worth it. You don't just have to take my word on it. There
      are folks around who have been doing it a lot longer than me, some who
      learned the lessons a lot harder than I did. Unfortunately, your team
      is going to have to learn for themselves, and that first means
      accepting the need to change. That will hurt, no way around it.
    • Show all 24 messages in this topic