41670Re: [scrumdevelopment] Re: Technical quality advocator
- Oct 2, 2009On Thu, Oct 1, 2009 at 11:54 PM, Inanc Gumus <inanc.gumus@...> wrote:
>One of the things I like about the way that XP describes planning, vs
> Hello Ron,
> --- In email@example.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.
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.
- << Previous post in topic Next post in topic >>