Primary Navigation

RE: [scrumdevelopment] monitoring bad SCRUM

Mike- At the worst case a sprint review meeting (held once a month at the end of the sprint) would uncover functionality that you thought was delivered but

Message 1 of 25
, Apr 25, 2003

0 Attachment

Mike—

At the worst case a sprint review meeting
(held once a month at the end of the sprint) would uncover functionality that
you thought was delivered but wasn’t. Even if the functionality isn’t of UI
work it can still be demonstrated at a Sprint Review. There may be details that
aren’t visible in any way but not that many per sprint. I was in a sprint
review earlier this week that demonstrated new functionality for users to
import bulk data into the database. There was no UI yet we still demo’d that
part of the back-end system. Additionally, even if one deceptive programmer lies
in the daily scrum meetings the lies should be caught by a tester on the team.
If the developer and tester collude to lie there’s nothing you can do until the
sprint review but you will find out then.

I have an interesting problem with
SCRUM. We do international project management and last year after
persuasive talks by Dan Rawsthorne we have started using SCRUM. It has been
working out amazingly well.

The last project we have started was
handled by a new project manager and has had some bad results. When we
did a little analysis of why things went wrong we realized that it was mostly
because we have learnt to just trust developer feedback on what has been done
and what hasn’t been done. When that feedback is accurate SCRUM works
great, however when that feedback is misleading the backlog becomes worthless.

In the meantime I have added other
fields to the backlog:

id

Task description

Original Effort Est.

Left over effort estimate

Dev (alias)

PM (verified/unverified)

QA (alias + status)

1122

Implement login dialog

2

0

Ruben

Roscoe: verified

Sureva: Done with test pass

1112

Implement print functionality

2

2

Ruben

Roscoe:

Sureva:

Basically all we are trying to do it to make sure that
PMs see that the feature is implemented to the spec and QA makes a pass on it before
we sign of on something as being “DONE”

Has anyone had this kind of experience? I can
see a big drawback with non GUI related stuff and the backend programming… but
what are you fellow-scrummers doing when SCRUM goes bad?

The content of this
e-mail is created only for viewing by the parties in the "To" and
"CC" line. The rights to forward or copy the text or
attachment are explicitly withheld. The message is provided "AS
IS" with no warranties, and confers no rights. You assume all risk for
your use of provided information.

(c)
2003 International Business Engineering Corporation. All rights
reserved.

Ok, great, so what I am hearing is that the extension of this log to have a tester and the PM sign off on the feature completion seems like a good addition.

Message 2 of 25
, Apr 25, 2003

0 Attachment

Ok, great, so what I am hearing is that
the extension of this log to have a tester and the PM sign off on the feature
completion seems like a good addition.

This problem is obviously not SCRUM
specific, Waterfall approaches have a lot more loopholes where people can inadvertently
(or not J ) misrepresent their progress.However I think SCRUM might offer an
opportunity to address this problem a lot better due to the binary state of the
tasks.

The components obviously do not have to be
GUI.The backend components should
have unit tests in which case the GUI is the JUnit or
cutest J.

At the worst case a
sprint review meeting (held once a month at the end of the sprint) would
uncover functionality that you thought was delivered but wasn’t. Even if
the functionality isn’t of UI work it can still be demonstrated at a
Sprint Review. There may be details that aren’t visible in any way but
not that many per sprint. I was in a sprint review earlier this week that
demonstrated new functionality for users to import bulk data into the database.
There was no UI yet we still demo’d that part of the back-end system.
Additionally, even if one deceptive programmer lies in the daily scrum meetings
the lies should be caught by a tester on the team. If the developer and tester
collude to lie there’s nothing you can do until the sprint review but you
will find out then.

I have an interesting problem with
SCRUM. We do international project management and last year after
persuasive talks by Dan Rawsthorne we have started using SCRUM. It has
been working out amazingly well.

The last project we have started was
handled by a new project manager and has had some bad results. When we
did a little analysis of why things went wrong we realized that it was mostly
because we have learnt to just trust developer feedback on what has been done
and what hasn’t been done. When that feedback is accurate SCRUM
works great, however when that feedback is misleading the backlog becomes
worthless.

In the meantime I have added other
fields to the backlog:

id

Task description

Original Effort Est.

Left over effort estimate

Dev (alias)

PM (verified/unverified)

QA (alias + status)

1122

Implement login dialog

2

0

Ruben

Roscoe: verified

Sureva: Done with test pass

1112

Implement print functionality

2

2

Ruben

Roscoe:

Sureva:

Basically all we are trying to do it to make sure that
PMs see that the feature is implemented to the spec and QA makes a pass on it
before we sign of on something as being “DONE”

Has anyone had this kind of experience? I can see
a big drawback with non GUI related stuff and the backend programming…
but what are you fellow-scrummers doing when SCRUM goes bad?

The content of this
e-mail is created only for viewing by the parties in the "To" and
"CC" line. The rights to forward or copy the text or
attachment are explicitly withheld. The message is provided "AS IS"
with no warranties, and confers no rights. You assume all risk for your use of
provided information.

(c)
2003 International Business Engineering Corporation. All rights
reserved.

In general I don$B!G(Bt know that I like the idea of signing things off-that always delays things as people are reluctant to put their name on a dotted line.

Message 3 of 25
, Apr 25, 2003

0 Attachment

In general I don’t know that I like
the idea of signing things off—that always delays things as people are
reluctant to put their name on a dotted line.

Could you instead gather the equivalent information
during the daily scrum? For example,

“Great, Mary. I’m glad to hear
you finished the XYZ task. Do we have tests for it? Are they part of the test
suite we run on the nightly build?”

If there are No answers to any of that,
add a task to the sprint backlog task list. Add the end if you still have “Test
XYZ” as a task you know that programming XYZ isn’t really done
either. (Programming can never be done till the testing is done.)

Ok, great, so what I am
hearing is that the extension of this log to have a tester and the PM sign off
on the feature completion seems like a good addition.

This problem is obviously
not SCRUM specific, Waterfall approaches have a lot more loopholes where people
can inadvertently (or not J ) misrepresent their progress. However I think SCRUM might
offer an opportunity to address this problem a lot better due to the binary
state of the tasks.

The components obviously
do not have to be GUI. The backend components should have unit tests in
which case the GUI is the JUnit or cutest J.

At the
worst case a sprint review meeting (held once a month at the end of the sprint)
would uncover functionality that you thought was delivered but wasn’t.
Even if the functionality isn’t of UI work it can still be demonstrated
at a Sprint Review. There may be details that aren’t visible in any way
but not that many per sprint. I was in a sprint review earlier this week that
demonstrated new functionality for users to import bulk data into the database.
There was no UI yet we still demo’d that part of the back-end system.
Additionally, even if one deceptive programmer lies in the daily scrum meetings
the lies should be caught by a tester on the team. If the developer and tester
collude to lie there’s nothing you can do until the sprint review but you
will find out then.

I have an interesting problem with
SCRUM. We do international project management and last year after
persuasive talks by Dan Rawsthorne we have started using SCRUM. It has
been working out amazingly well.

The last project we have started was
handled by a new project manager and has had some bad results. When we
did a little analysis of why things went wrong we realized that it was mostly
because we have learnt to just trust developer feedback on what has been done
and what hasn’t been done. When that feedback is accurate SCRUM
works great, however when that feedback is misleading the backlog becomes
worthless.

In the meantime I have added other
fields to the backlog:

id

Task description

Original Effort Est.

Left over effort estimate

Dev (alias)

PM (verified/unverified)

QA (alias + status)

1122

Implement login dialog

2

0

Ruben

Roscoe: verified

Sureva: Done with test pass

1112

Implement print functionality

2

2

Ruben

Roscoe:

Sureva:

Basically all we are trying to do it to make sure that
PMs see that the feature is implemented to the spec and QA makes a pass on it before
we sign of on something as being “DONE”

Has anyone had this kind of experience? I can
see a big drawback with non GUI related stuff and the backend
programming… but what are you fellow-scrummers doing when SCRUM goes bad?

The content of this
e-mail is created only for viewing by the parties in the "To" and
"CC" line. The rights to forward or copy the text or
attachment are explicitly withheld. The message is provided "AS
IS" with no warranties, and confers no rights. You assume all risk for
your use of provided information.

(c)
2003 International Business Engineering Corporation. All rights
reserved.

I have an interesting problem with
SCRUM.We do international
project management and last year after persuasive talks by Dan Rawsthorne we
have started using SCRUM.It has
been working out amazingly well.

The last project we have started
was handled by a new project manager and has had some bad results.When we did a little analysis of why
things went wrong we realized that it was mostly because we have learnt to
just trust developer feedback on what has been done and what hasn’t been
done.When that feedback is
accurate SCRUM works great, however when that feedback is misleading the
backlog becomes worthless.

In the meantime I have added other
fields to the backlog:

id

Task
description

Original Effort
Est.

Left over effort
estimate

Dev
(alias)

PM
(verified/unverified)

QA (alias +
status)

1122

Implement login
dialog

2

0

Ruben

Roscoe:
verified

Sureva:
Done with test pass

1112

Implement print
functionality

2

2

Ruben

Roscoe:

Sureva:

Basically all we are trying to do
it to make sure that PMs see that the feature is implemented to the spec and
QA makes a pass on it before we sign of on something as being
“DONE”

Has anyone had this kind of
experience?I can see a big
drawback with non GUI related stuff and the backend programming… but what are
you fellow-scrummers doing when SCRUM goes bad?

The
content of this e-mail is created only for viewing by the parties in the "To"
and "CC" line. The rights to forward or copy the text or
attachment are explicitly withheld. The message is provided "AS IS" with
no warranties, and confers no rights. You assume all risk for your use of
provided information.

(c)
2003 International Business Engineering Corporation. All rights
reserved.

I don t really know why people gave incorrect feedback. I don t believe anyone purposefully plans on lying. There could be several reasons for it: sometimes

Message 5 of 25
, Apr 26, 2003

0 Attachment

I don’t really know why people gave
incorrect feedback.I don’t
believe anyone purposefully plans on lying.There could be several reasons for it:
sometimes people feel pressured to show progress, sometimes they just feel like
they are so close to completion of a certain feature set that they say “I
am done” at the SCRUM meeting, some people just don’t go to the level
of detail of implementation as they are supposed to.For example if you have to have a login
dialog with a help tool tip the developer might say: “yeah it’s done”,
but the tooltip isn’t there.

Different cultures treat bad results very
differently too.In US speaking out
about your roadblocks is encouraged.When we deal with some of our Asian partners we have to literally extract
the bad information out of the personnel.I don’t know if there are any
grounds/justification for generalizations, so I am not going to make them.That was just my experience so far.

I have an interesting problem with
SCRUM.We do international
project management and last year after persuasive talks by Dan Rawsthorne we
have started using SCRUM.It has
been working out amazingly well.

The last project we have started was
handled by a new project manager and has had some bad results.When we did a little analysis of why
things went wrong we realized that it was mostly because we have learnt to just
trust developer feedback on what has been done and what hasn’t been
done.When that feedback is
accurate SCRUM works great, however when that feedback is misleading the
backlog becomes worthless.

In the meantime I have added other
fields to the backlog:

id

Task description

Original Effort Est.

Left over effort estimate

Dev (alias)

PM (verified/unverified)

QA (alias + status)

1122

Implement login dialog

2

0

Ruben

Roscoe: verified

Sureva: Done with test pass

1112

Implement print functionality

2

2

Ruben

Roscoe:

Sureva:

Basically all we are trying to do it
to make sure that PMs see that the feature is implemented to the spec and QA
makes a pass on it before we sign of on something as being “DONE”

Has anyone had this kind of
experience?I can see a big
drawback with non GUI related stuff and the backend programming… but what
are you fellow-scrummers doing when SCRUM goes bad?

The
content of this e-mail is created only for viewing by the parties in the
"To" and "CC" line. The rights to forward or
copy the text or attachment are explicitly withheld. The message is
provided "AS IS" with no warranties, and confers no rights. You
assume all risk for your use of provided information.

(c)
2003 International Business Engineering Corporation. All rights
reserved.

I have seen this also: colleagues who have the hardest time to raise a red flag when problems cause delays. In my experience they are also, often, among the

Message 6 of 25
, Apr 27, 2003

0 Attachment

I have seen this also: colleagues who have the hardest time to "raise
a red flag" when problems cause delays. In my experience they are
also, often, among the most diligent and quality-conscious workers on
the team.

Now I'm of the loud-mouth variety, and it's easy for me to say "I've
uncovered a problem, and I need another half day". But I'm wondering
if there are any people reading this who find the declaration of
roadblocks difficult, and if they could tell us how this feels from
their point of view?

Does Scrum depend on a team's acceptance/adoption of a communication
paradigm that is uncomfortable for some personalities or cultures? If
so, is there a way to adapt it so all can participate fruitfully?
Those with good experiences in this area: your comments would be
helpful to us.

OK, you quiet people, now is your chance to tell the loud people your
side of things!

deb

--- In scrumdevelopment@yahoogroups.com, "Mike" <ezxs@f...> wrote:
> I don't really know why people gave incorrect feedback. I don't
believe
> anyone purposefully plans on lying. There could be several reasons
for
> it: sometimes people feel pressured to show progress, sometimes they
> just feel like they are so close to completion of a certain feature
set
> that they say "I am done" at the SCRUM meeting, some people just
don't
> go to the level of detail of implementation as they are supposed to.
> For example if you have to have a login dialog with a help tool tip
the
> developer might say: "yeah it's done", but the tooltip isn't there.
>
> Different cultures treat bad results very differently too. In US
> speaking out about your roadblocks is encouraged. When we deal with
> some of our Asian partners we have to literally extract the bad
> information out of the personnel. I don't know if there are any
> grounds/justification for generalizations, so I am not going to make
> them. That was just my experience so far.
>
> Mike.
>
> -----Original Message-----
> From: Clarke Ching [mailto:clarke.ching@f...]
> Sent: Friday, April 25, 2003 11:54 PM
> To: scrumdevelopment@yahoogroups.com
> Subject: RE: [scrumdevelopment] monitoring bad SCRUM
>
> Hi Mike,
>
> Why do you think the developers gave incorrect feedback (or lied)?
>
> Did they not trust the new PM?
>
> Clarke Ching
> Scotland
> -----Original Message-----
> From: Mike [mailto:ezxs@f...]
> Sent: 25 April 2003 20:51
> To: scrumdevelopment@yahoogroups.com
> Subject: [scrumdevelopment] monitoring bad SCRUM
> I have an interesting problem with SCRUM. We do international
project
> management and last year after persuasive talks by Dan Rawsthorne we
> have started using SCRUM. It has been working out amazingly well.
>
> The last project we have started was handled by a new project
manager
> and has had some bad results. When we did a little analysis of why
> things went wrong we realized that it was mostly because we have
learnt
> to just trust developer feedback on what has been done and what
hasn't
> been done. When that feedback is accurate SCRUM works great,
however
> when that feedback is misleading the backlog becomes worthless.
>
> In the meantime I have added other fields to the backlog:
>
>
> id
> Task description
> Original Effort Est.
> Left over effort estimate
> Dev (alias)
> PM (verified/unverified)
> QA (alias + status)
>
> 1122
> Implement login dialog
> 2
> 0
> Ruben
> Roscoe: verified
> Sureva: Done with test pass
>
> 1112
> Implement print functionality
> 2
> 2
> Ruben
> Roscoe:
> Sureva:
>
>
>
>
>
>
>
>
>
> Basically all we are trying to do it to make sure that PMs see that
the
> feature is implemented to the spec and QA makes a pass on it before
we
> sign of on something as being "DONE"
>
> Has anyone had this kind of experience? I can see a big drawback
with
> non GUI related stuff and the backend programming. but what are you
> fellow-scrummers doing when SCRUM goes bad?
>
>
> _____
>
> Mike Borozdin // IBE Corporation
> office: 425.990.4545
> cell: 206.850.3294
> msft: 425.705.6754
> web: <http://ibe-us.com> ibe-us.com
> The content of this e-mail is created only for viewing by the
parties in
> the "To" and "CC" line. The rights to forward or copy the text or
> attachment are explicitly withheld. The message is provided "AS IS"
with
> no warranties, and confers no rights. You assume all risk for your
use
> of provided information.
> (c) 2003 International Business Engineering Corporation. All rights
> reserved.
>
>
>
>
> To Post a message, send it to: scrumdevelopment@e...
> To Unsubscribe, send a blank message to:
> scrumdevelopment-unsubscribe@e...
>
> Your use of Yahoo! Groups is subject to the Yahoo!
> <http://docs.yahoo.com/info/terms/> Terms of Service.
>
>
>
>
> Yahoo! Groups Sponsor
>
>
>
>
>
<http://rd.yahoo.com/M=247865.3003379.4507215.2595810/D=egroupweb/S=17
07
> 209021:HM/A=1482387/R=0/*http:/ads.x10.com/?
bHlhaG9vaG0xLmRhd=1051340044
> %
3eM=247865.3003379.4507215.2595810/D=egroupweb/S=1707209021:HM/A=14823
8
> 7/R=1=1051340044%
3eM=247865.3003379.4507215.2595810/D=egroupweb/S=170720
> 9021:HM/A=1482387/R=2>
>
>
> <http://us.adserver.yahoo.com/l?
M=247865.3003379.4507215.2595810/D=egrou
> pmail/S=:HM/A=1482387/rand=956146690>
>
> To Post a message, send it to: scrumdevelopment@e...
> To Unsubscribe, send a blank message to:
> scrumdevelopment-unsubscribe@e...
>
> Your use of Yahoo! Groups is subject to the Yahoo!
> <http://docs.yahoo.com/info/terms/> Terms of Service.

Mike Cohn

The daily scrum helps protect against this. Even if I don t want to admit I m having troubles with task A it is hard for me to hide that for long. a) Either I

Message 7 of 25
, Apr 27, 2003

0 Attachment

The daily scrum helps protect against this. Even if I don't want to admit
I'm having troubles with task A it is hard for me to hide that for long.

a) Either I stay on it for a long time and someone in a Scrum meeting asks,
"Weren't you supposed to be done with that 3 weeks ago?"
b) Or, I move onto other tasks, leaving task A unfinished but telling the
team it's done. Whoever is on the team doing testing will notice this or it
will come up at the sprint review.
c) Or, I code something that works in 95% of the cases and is good enough to
pass tests but as soon as a real user gets it they'll start to find all the
problems and fixing them will be a major effort.

Option (c) can happen with any process. If the result of the sprint is given
to users to at least experiment with then they'll find it at the end of the
sprint so it goes undetected for 30 days or so at most. The built-in
inspection processes of Scrum will help with help identify (a) or (b) if
they're tried.

I have seen this also: colleagues who have the hardest time to "raise
a red flag" when problems cause delays. In my experience they are
also, often, among the most diligent and quality-conscious workers on
the team.

Now I'm of the loud-mouth variety, and it's easy for me to say "I've
uncovered a problem, and I need another half day". But I'm wondering
if there are any people reading this who find the declaration of
roadblocks difficult, and if they could tell us how this feels from
their point of view?

Does Scrum depend on a team's acceptance/adoption of a communication
paradigm that is uncomfortable for some personalities or cultures? If
so, is there a way to adapt it so all can participate fruitfully?
Those with good experiences in this area: your comments would be
helpful to us.

OK, you quiet people, now is your chance to tell the loud people your
side of things!

deb

--- In scrumdevelopment@yahoogroups.com, "Mike" <ezxs@f...> wrote:
> I don't really know why people gave incorrect feedback. I don't
believe
> anyone purposefully plans on lying. There could be several reasons
for
> it: sometimes people feel pressured to show progress, sometimes they
> just feel like they are so close to completion of a certain feature
set
> that they say "I am done" at the SCRUM meeting, some people just
don't
> go to the level of detail of implementation as they are supposed to.
> For example if you have to have a login dialog with a help tool tip
the
> developer might say: "yeah it's done", but the tooltip isn't there.
>
> Different cultures treat bad results very differently too. In US
> speaking out about your roadblocks is encouraged. When we deal with
> some of our Asian partners we have to literally extract the bad
> information out of the personnel. I don't know if there are any
> grounds/justification for generalizations, so I am not going to make
> them. That was just my experience so far.
>
> Mike.
>
> -----Original Message-----
> From: Clarke Ching [mailto:clarke.ching@f...]
> Sent: Friday, April 25, 2003 11:54 PM
> To: scrumdevelopment@yahoogroups.com
> Subject: RE: [scrumdevelopment] monitoring bad SCRUM
>
> Hi Mike,
>
> Why do you think the developers gave incorrect feedback (or lied)?
>
> Did they not trust the new PM?
>
> Clarke Ching
> Scotland
> -----Original Message-----
> From: Mike [mailto:ezxs@f...]
> Sent: 25 April 2003 20:51
> To: scrumdevelopment@yahoogroups.com
> Subject: [scrumdevelopment] monitoring bad SCRUM
> I have an interesting problem with SCRUM. We do international
project
> management and last year after persuasive talks by Dan Rawsthorne we
> have started using SCRUM. It has been working out amazingly well.
>
> The last project we have started was handled by a new project
manager
> and has had some bad results. When we did a little analysis of why
> things went wrong we realized that it was mostly because we have
learnt
> to just trust developer feedback on what has been done and what
hasn't
> been done. When that feedback is accurate SCRUM works great,
however
> when that feedback is misleading the backlog becomes worthless.
>
> In the meantime I have added other fields to the backlog:
>
>
> id
> Task description
> Original Effort Est.
> Left over effort estimate
> Dev (alias)
> PM (verified/unverified)
> QA (alias + status)
>
> 1122
> Implement login dialog
> 2
> 0
> Ruben
> Roscoe: verified
> Sureva: Done with test pass
>
> 1112
> Implement print functionality
> 2
> 2
> Ruben
> Roscoe:
> Sureva:
>
>
>
>
>
>
>
>
>
> Basically all we are trying to do it to make sure that PMs see that
the
> feature is implemented to the spec and QA makes a pass on it before
we
> sign of on something as being "DONE"
>
> Has anyone had this kind of experience? I can see a big drawback
with
> non GUI related stuff and the backend programming. but what are you
> fellow-scrummers doing when SCRUM goes bad?
>
>
> _____
>
> Mike Borozdin // IBE Corporation
> office: 425.990.4545
> cell: 206.850.3294
> msft: 425.705.6754
> web: <http://ibe-us.com> ibe-us.com
> The content of this e-mail is created only for viewing by the
parties in
> the "To" and "CC" line. The rights to forward or copy the text or
> attachment are explicitly withheld. The message is provided "AS IS"
with
> no warranties, and confers no rights. You assume all risk for your
use
> of provided information.
> (c) 2003 International Business Engineering Corporation. All rights
> reserved.
>
>
>
>
> To Post a message, send it to: scrumdevelopment@e...
> To Unsubscribe, send a blank message to:
> scrumdevelopment-unsubscribe@e...
>
> Your use of Yahoo! Groups is subject to the Yahoo!
> <http://docs.yahoo.com/info/terms/> Terms of Service.
>
>
>
>
> Yahoo! Groups Sponsor
>
>
>
>
>
<http://rd.yahoo.com/M=247865.3003379.4507215.2595810/D=egroupweb/S=17
07
> 209021:HM/A=1482387/R=0/*http:/ads.x10.com/?
bHlhaG9vaG0xLmRhd=1051340044
> %
3eM=247865.3003379.4507215.2595810/D=egroupweb/S=1707209021:HM/A=14823
8
> 7/R=1=1051340044%
3eM=247865.3003379.4507215.2595810/D=egroupweb/S=170720
> 9021:HM/A=1482387/R=2>
>
>
> <http://us.adserver.yahoo.com/l?
M=247865.3003379.4507215.2595810/D=egrou
> pmail/S=:HM/A=1482387/rand=956146690>
>
> To Post a message, send it to: scrumdevelopment@e...
> To Unsubscribe, send a blank message to:
> scrumdevelopment-unsubscribe@e...
>
> Your use of Yahoo! Groups is subject to the Yahoo!
> <http://docs.yahoo.com/info/terms/> Terms of Service.

... workers ... In light of Seek help only when you ve exhausted all your resources , that statement was something I m glad to see articulated. Mike Cohn s

Message 8 of 25
, Apr 28, 2003

0 Attachment

> I have seen this also: colleagues who have the
> hardest time to "raise a red flag" when problems
> cause delays. In my experience they are also, often,

> among the most diligent and quality-conscious

workers

> on the team.

In light of "Seek help only when you've exhausted all
your resources", that statement was something I'm glad
to see articulated.

Mike Cohn's response sums up my hopes for Scrum
improving this situation. Few want to risk be
perceived as a nay-sayer or chicken little, and Scrums
discussion opening Scrum meeting mixed with intense
team work seems like it would reduce the amount of
cave time for developers and support communication.
As the daily meetings are stand-up and not a weekly
status meeting, working out questions and problems in
a seperate 2-3 person meeting should also help the
person feel off-the-spot. The remainder of the team
can then truly expect "no [immediate] news is good
news" and a follow-up at tomorows meeting.

> I have seen this also: colleagues who have the
> hardest time to "raise
> a red flag" when problems cause delays. In my
> experience they are
> also, often, among the most diligent and
> quality-conscious workers on
> the team.
>
> Now I'm of the loud-mouth variety, and it's easy for
> me to say "I've
> uncovered a problem, and I need another half day".
> But I'm wondering
> if there are any people reading this who find the
> declaration of
> roadblocks difficult, and if they could tell us how
> this feels from
> their point of view?
>
> Does Scrum depend on a team's acceptance/adoption of
> a communication
> paradigm that is uncomfortable for some
> personalities or cultures? If
> so, is there a way to adapt it so all can
> participate fruitfully?
> Those with good experiences in this area: your
> comments would be
> helpful to us.
>
> OK, you quiet people, now is your chance to tell the
> loud people your
> side of things!
>
> deb
>
> --- In scrumdevelopment@yahoogroups.com, "Mike"
> <ezxs@f...> wrote:
> > I don't really know why people gave incorrect
> feedback. I don't
> believe
> > anyone purposefully plans on lying. There could
> be several reasons
> for
> > it: sometimes people feel pressured to show
> progress, sometimes they
> > just feel like they are so close to completion of
> a certain feature
> set
> > that they say "I am done" at the SCRUM meeting,
> some people just
> don't
> > go to the level of detail of implementation as
> they are supposed to.
> > For example if you have to have a login dialog
> with a help tool tip
> the
> > developer might say: "yeah it's done", but the
> tooltip isn't there.
> >
> > Different cultures treat bad results very
> differently too. In US
> > speaking out about your roadblocks is encouraged.
> When we deal with
> > some of our Asian partners we have to literally
> extract the bad
> > information out of the personnel. I don't know if
> there are any
> > grounds/justification for generalizations, so I am
> not going to make
> > them. That was just my experience so far.
> >
> > Mike.
> >
> > -----Original Message-----
> > From: Clarke Ching [mailto:clarke.ching@f...]
> > Sent: Friday, April 25, 2003 11:54 PM
> > To: scrumdevelopment@yahoogroups.com
> > Subject: RE: [scrumdevelopment] monitoring bad
> SCRUM
> >
> > Hi Mike,
> >
> > Why do you think the developers gave incorrect
> feedback (or lied)?
> >
> > Did they not trust the new PM?
> >
> > Clarke Ching
> > Scotland
> > -----Original Message-----
> > From: Mike [mailto:ezxs@f...]
> > Sent: 25 April 2003 20:51
> > To: scrumdevelopment@yahoogroups.com
> > Subject: [scrumdevelopment] monitoring bad SCRUM
> > I have an interesting problem with SCRUM. We do
> international
> project
> > management and last year after persuasive talks by
> Dan Rawsthorne we
> > have started using SCRUM. It has been working out
> amazingly well.
> >
> > The last project we have started was handled by a
> new project
> manager
> > and has had some bad results. When we did a
> little analysis of why
> > things went wrong we realized that it was mostly
> because we have
> learnt
> > to just trust developer feedback on what has been
> done and what
> hasn't
> > been done. When that feedback is accurate SCRUM
> works great,
> however
> > when that feedback is misleading the backlog
> becomes worthless.
> >
> > In the meantime I have added other fields to the
> backlog:
> >
> >
> > id
> > Task description
> > Original Effort Est.
> > Left over effort estimate
> > Dev (alias)
> > PM (verified/unverified)
> > QA (alias + status)
> >
> > 1122
> > Implement login dialog
> > 2
> > 0
> > Ruben
> > Roscoe: verified
> > Sureva: Done with test pass
> >
> > 1112
> > Implement print functionality
> > 2
> > 2
> > Ruben
> > Roscoe:
> > Sureva:
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Basically all we are trying to do it to make sure
> that PMs see that
> the
> > feature is implemented to the spec and QA makes a
> pass on it before
> we
> > sign of on something as being "DONE"
> >
> > Has anyone had this kind of experience? I can see
> a big drawback
> with
> > non GUI related stuff and the backend programming.
> but what are you
> > fellow-scrummers doing when SCRUM goes bad?
> >
> >
> > _____
> >
> > Mike Borozdin // IBE Corporation
> > office: 425.990.4545
> > cell: 206.850.3294
> > msft: 425.705.6754
> > web: <http://ibe-us.com> ibe-us.com
> > The content of this e-mail is created only for
> viewing by the
> parties in
> > the "To" and "CC" line. The rights to forward or
> copy the text or
> > attachment are explicitly withheld. The message is
> provided "AS IS"
> with
> > no warranties, and confers no rights. You assume
> all risk for your
> use
> > of provided information.
> > (c) 2003 International Business Engineering
> Corporation. All rights
> > reserved.
> >
> >
> >
> >
> > To Post a message, send it to:
> scrumdevelopment@e...
> > To Unsubscribe, send a blank message to:
> > scrumdevelopment-unsubscribe@e...
> >
>

=== message truncated ===

__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.http://search.yahoo.com

Hal Macomber

I m wondering about the experience people have with pair programming. I would guess there would be less of a problem raising the flag . First, with two

Message 9 of 25
, Apr 28, 2003

0 Attachment

I'm wondering about the experience people have with pair programming. I would guess there would be less of a problem 'raising the flag'. First, with two people on a task they would be more likely to work through the problem. Second, with two people each individual is already getting help. Asking for some more time or more help looks like a small step for the pair to take. What is your experience??

Dean Goodmanson <goodmansond@...> wrote:

> I have seen this also: colleagues who have the > hardest time to "raise a red flag" when problems > cause delays. In my experience they are also, often,

> among the most diligent and quality-consciousworkers> on the team.

In light of "Seek help only when you've exhausted allyour resources", that statement was something I'm gladto see articulated.

Mike Cohn's response sums up my hopes for Scrumimproving this situation. Few want to risk beperceived as a nay-sayer or chicken little, and Scrumsdiscussion opening Scrum meeting mixed with intenseteam work seems like it would reduce the amount ofcave time for developers and support communication. As the daily meetings are stand-up and not a weeklystatus meeting, working out questions and problems ina seperate 2-3 person meeting should also help theperson feel off-the-spot. The remainder of the teamcan then truly expect "no [immediate] news is goodnews" and a follow-up at tomorows meeting.

--- Deb <deborah@...> wrote:> I have seen this also: colleagues who have the> hardest time to "raise > a red flag" when problems cause delays. In my> experience they are > also, often, among the most diligent and> quality-conscious workers on > the team. > > Now I'm of the loud-mouth variety, and it's easy for> me to say "I've > uncovered a problem, and I need another half day".> But I'm wondering > if there are any people reading this who find the> declaration of > roadblocks difficult, and if they could tell us how> this feels from > their point of view?> > Does Scrum depend on a team's acceptance/adoption of> a communication > paradigm that is uncomfortable for some> personalities or cultures? If > so, is there a way to adapt it so all can> participate fruitfully? > Those with good experiences in this area: your> comments would be > helpful to us.> > OK, you quiet people, now is your chance to tell the> loud people your > side of things!> > deb> > --- In scrumdevelopment@yahoogroups.com, "Mike"> <ezxs@f...> wrote:> > I don't really know why people gave incorrect> feedback. I don't > believe> > anyone purposefully plans on lying. There could> be several reasons > for> > it: sometimes people feel pressured to show> progress, sometimes they> > just feel like they are so close to completion of> a certain feature > set> > that they say "I am done" at the SCRUM meeting,> some people just > don't> > go to the level of detail of implementation as> they are supposed to.> > For example if you have to have a login dialog> with a help tool tip > the> > developer might say: "yeah it's done", but the> tooltip isn't there.> > > > Different cultures treat bad results very> differently too. In US> > speaking out about your roadblocks is encouraged. > When we deal with> > some of our Asian partners we have to literally> extract the bad> > information out of the personnel. I don't know if> there are any> > grounds/justification for generalizations, so I am> not going to make> > them. That was just my experience so far.> > > > Mike.> >

... I wonder whether seek help the moment it might improve your situation would be a better rule to live by. Ron Jeffries www.XProgramming.com It is a bad

Message 10 of 25
, Apr 28, 2003

0 Attachment

On Monday, April 28, 2003, at 8:18:59 AM, Dean Goodmanson wrote:

> In light of "Seek help only when you've exhausted all
> your resources", that statement was something I'm glad
> to see articulated.

I wonder whether "seek help the moment it might improve your situation"
would be a better rule to live by.

Ron Jeffries
www.XProgramming.com
It is a bad plan that admits of no modifications. -- Publius Syrus (ca. 42 BCE)

Ron Jeffries

... As I become more and more familiar with a particular pair, I m more and more ready to express confusion or ignorance the moment I notice it. I get more and

Message 11 of 25
, Apr 28, 2003

0 Attachment

On Monday, April 28, 2003, at 8:48:41 AM, Hal Macomber wrote:

> I'm wondering about the experience people have with pair programming. I would guess there
> would be less of a problem 'raising the flag'. First, with two people on a task they would
> be more likely to work through the problem. Second, with two people each individual is
> already getting help. Asking for some more time or more help looks like a small step for the
> pair to take. What is your experience??

As I become more and more familiar with a particular pair, I'm more and
more ready to express confusion or ignorance the moment I notice it. I get
more and more used to his gentle reminders "semicolon", or "do we need a
test".

And I get more and more comfortable expressing my confusion and ignorance
even with a new pair. And even in other places where I might feel the need
to seem like I know everything. <humor type="dubious">Of course, since I do
know /nearly/ everything, this skill is of limited use, but I was thinking
that for actual mortals, it could be really good.</humor>

But seriously. Help is good. The more I get, the more I give, the better I
do.

Ron Jeffries
www.XProgramming.com
No one expects the Spanish Inquisition ...

Mike Beedle

... True, but I would argue that the combination of Daily Scrums, Pairing, Continuous Integration, Daily Build, Unit Tests, and Acceptance Tests, make it

> a) Either I stay on it for a long time and
> someone in a Scrum meeting asks, "Weren't you
> supposed to be done with that 3 weeks ago?"

In Scrum you can't lie. If you say you were
supposed to be done 3 weeks ago, the team will
notice within the first 24 hrs. and the team
will react _immediately_ to it because your pair
will notice that you didn't work on this, your
unit tests won't pass, the build won't have the
functionality, the customer will notice he/she
can't acceptance test it, etc.

So it will be _very hard_ to go unnoticed.

But that's the whole premise of Scrum -- nothing
will go unmonitored for extended periods of time
i.e. (> t 24).

> Whoever is on the team doing testing will
> notice this or it will come up at the sprint
> review.

In Scrum _everyone_ will be doing testing every
day:

- the developers will be doing unit testing
- the developers will be doing automated
acceptance testing
- the customer/stakeholders will be doing automated/
non-automated acceptance testing and giving
continuous feedback

> If the result of the sprint is given
> to users to at least experiment with then
> they'll find it at the end of the
> sprint so it goes undetected for 30 days or
> so at most.

I would say that the Scrum practices will ensure
that none of the above _ever_ happens,

-Mike

Mike Cohn

I disagree but only in the subtle cases. If I m charged with writing a piece of code and work with a pair to do it we may get it to a certain point that my

Message 13 of 25
, Apr 28, 2003

0 Attachment

I disagree but only in the subtle cases. If I'm charged with writing a piece
of code and work with a pair to do it we may get it to a certain point that
my pair thinks it's done and it appears done because it passes QA's tests.
Yet, I'm aware of some subtle times when it will fail and I don't bring them
up because I don't want to rewrite that area. For example, long ago I
remember writing code for an interactive voice response system and there
were lots of intricate rules about when to add various elements to the phone
number (country code, area, 1+0, etc.). Most international numbers followed
the same rules. I don't remember the specifics but there were a few
occasions where international dialing was a little different. If I had been
pairing with someone I could have hidden my knowledge of that and QA
wouldn't have found it either. It is possible to hide some unfinished work.
I don't think any process can prevent this type of behavior.

> a) Either I stay on it for a long time and
> someone in a Scrum meeting asks, "Weren't you
> supposed to be done with that 3 weeks ago?"

In Scrum you can't lie. If you say you were
supposed to be done 3 weeks ago, the team will
notice within the first 24 hrs. and the team
will react _immediately_ to it because your pair
will notice that you didn't work on this, your
unit tests won't pass, the build won't have the
functionality, the customer will notice he/she
can't acceptance test it, etc.

So it will be _very hard_ to go unnoticed.

But that's the whole premise of Scrum -- nothing
will go unmonitored for extended periods of time
i.e. (> t 24).

> Whoever is on the team doing testing will
> notice this or it will come up at the sprint
> review.

In Scrum _everyone_ will be doing testing every
day:

- the developers will be doing unit testing
- the developers will be doing automated
acceptance testing
- the customer/stakeholders will be doing automated/
non-automated acceptance testing and giving
continuous feedback

Mike, While SCRUM makes misrepresentation of progress A LOT harder then any other project management methodology it can happen (or at least did happen to me

Message 14 of 25
, Apr 28, 2003

0 Attachment

Mike,

While SCRUM makes misrepresentation of progress
A LOT harder then any other project management methodology it can happen (or at
least did happen to me J).If you refer to my
previous e-mail I’d say that the problem is mostly the lack of detail or
a binary state for a non-binary task i.e. a solution that makes 95% of the testcases pass.

Pairing would make things like that a lot
harder to hide because in paired programming there is already a peer that sees
the same problem as you do.That
makes it easier to voice the problem at the daily SCRUM.

A SCRUM master particular to detail and
technically savvy is another way those situations are made less likely.As a SCRUM master master
unfortunately I am at their mercy a lot of times L.

I am going to see what additional fields
to the backlog do and post the success/failure results to the list.

--- Mike Cohn
<mike@...> wrote:> The daily scrum helps protect against this.
Even > if I don't want to admit I'm having troubles > with task A it is hard for me to hide that
for long.

True, but I would argue that the combination of Daily Scrums, Pairing, Continuous Integration, Daily Build, Unit Tests, and Acceptance Tests, make it _impossible_ to hide any troubles
whatsoever.

--- Mike Cohn
<mike@...> wrote:> a) Either I stay on it for a long time and > someone in a Scrum meeting asks,
"Weren't you > supposed to be done with that 3 weeks
ago?"

In Scrum you can't lie. If you say you weresupposed to be done 3 weeks ago, the team willnotice within the first 24 hrs. and the teamwill react _immediately_ to it because your pairwill notice that you didn't work on this, yourunit tests won't pass, the build won't have thefunctionality, the customer will notice he/shecan't acceptance test it, etc.

So it will be _very hard_ to go unnoticed.

But that's the whole premise of Scrum -- nothing will go unmonitored for extended periods of timei.e. (> t 24).

This will not happen in Scrum because _everyone_will notice the expected functionality:

* is not passing unit tests* is not in configuration management* is not in the build* can't be acceptance tested* etc.

_even_ if it is reported as done in the Daily
Scrums.

--- Mike Cohn
<mike@...> wrote:> Whoever is on the team doing testing will > notice this or it will come up at the sprint > review.

In Scrum _everyone_ will be doing testing everyday:

- the developers will be doing unit testing - the developers will be doing automated acceptance testing - the customer/stakeholders will be doing
automated/ non-automated acceptance
testing and giving continuous feedback

--- Mike Cohn
<mike@...> wrote:> c) Or, I code something that works in 95% of > the cases and is good enough to pass tests ..

Hopefully something working at 95% won't pass 100% of the tests ;-) -- or else we might have thewrong tests.

--- Mike Cohn
<mike@...> wrote:> but as soon as a real user gets it they'll > start to find all the problems and fixing
them > will be a major effort.

--- Mike Cohn
<mike@...> wrote:> If the result of the sprint is given> to users to at least experiment with then > they'll find it at the end of the> sprint so it goes undetected for 30 days or > so at most.

I would say that the Scrum practices will ensurethat none of the above _ever_ happens,

So all of what you say seems possible -- for some period of time. And it is true that people lie, shade the truth, and leave out important details. If we are

Message 15 of 25
, Apr 28, 2003

0 Attachment

So all of what you say seems possible -- for some period of time. And it is true that people lie, shade the truth, and leave out important details. If we are talking about criminal behavior -- intent to deceive for some personal gain -- then we know what to do: get rid of the team member. But I have found people behave this way out of frustration that work isn't proceeding the way they want, embarassment that they can't perform as expected, resignation with some aspect of the project, etc. The only thing I've seen to overcome the power of those moods is having ownership in the successful outcome of the project.

Some people argue that of course my team members are committed to the success of the project. However the behaviors described in this thread are all too familiar. We can't say that people demonstrating these behaviors take full ownership in success. It is the project leader's responsibility to continue to engage team members as owners of the promise to the customer. I say 'continue to engage' because the nature of our lives is that other things are always coming up -- the school play, the soccer match, our spouse's birthday, a more challenging assignment, a redirection of the project, abandonning code, etc. -- competing with the big commitments we've made. Without explict acts of re-engaging ownership individuals and the team will eventually drift from their commitment.

I've been directly involved with 30-40 software projects. None were done on an agile basis. For the last 4 years I have managed and consulted to organizations doing projects on a lean basis. It seems to me the combination of Scrum practices with ongoing care for ownership will allow teams to avoid the isues identified.

Mike Cohn <mike@...> wrote:

I disagree but only in the subtle cases. If I'm charged with writing a pieceof code and work with a pair to do it we may get it to a certain point thatmy pair thinks it's done and it appears done because it passes QA's tests.Yet, I'm aware of some subtle times when it will fail and I don't bring themup because I don't want to rewrite that area. For example, long ago Iremember writing code for an interactive voice response system and therewere lots of intricate rules about when to add various elements to the phonenumber (country code, area, 1+0, etc.). Most international numbers followedthe same rules. I don't remember the specifics but there were a fewoccasions where international dialing was a little different. If I had beenpairing with someone I could have hidden my knowledge of that and QAwouldn't have found it either. It is possible to hide some unfinished work.I don't think any process can prevent this type of behavior.

--- Mike Cohn <mike@...> wrote:> The daily scrum helps protect against this. Even > if I don't want to admit I'm having troubles > with task A it is hard for me to hide that for long.

True, but I would argue that the combination of Daily Scrums, Pairing, Continuous Integration, Daily Build, Unit Tests, and Acceptance Tests, make it _impossible_ to hide any troubles whatsoever.

--- Mike Cohn <mike@...> wrote:> a) Either I stay on it for a long time and > someone in a Scrum meeting asks, "Weren't you > supposed to be done with that 3 weeks ago?"

In Scrum you can't lie. If you say you weresupposed to be done 3 weeks ago, the team willnotice within the first 24 hrs. and the teamwill react _immediately_ to it because your pairwill notice that you didn't work on this, yourunit tests won't pass, the build won't have thefunctionality, the customer will notice he/shecan't acceptance test it, etc.

So it will be _very hard_ to go unnoticed.

But that's the whole premise of Scrum -- nothing will go unmonitored for extended periods of timei.e. (> t 24).

This will not happen in Scrum because _everyone_will notice the expected functionality:

* is not passing unit tests* is not in configuration management* is not in the build* can't be acceptance tested* etc.

_even_ if it is reported as done in the Daily Scrums.

--- Mike Cohn <mike@...> wrote:> Whoever is on the team doing testing will > notice this or it will come up at the sprint > review.

In Scrum _everyone_ will be doing testing everyday:

- the developers will be doing unit testing - the developers will be doing automated acceptance testing - the customer/stakeholders will be doing automated/ non-automated acceptance testing and giving continuous feedback

--- Mike Cohn <mike@...> wrote:> c) Or, I code something that works in 95% of > the cases and is good enough to pass tests ..

Hopefully something working at 95% won't pass 100% of the tests ;-) -- or else we might have thewrong tests.

--- Mike Cohn <mike@...> wrote:> but as soon as a real user gets it they'll > start to find all the problems and fixing them > will be a major effort.

--- Mike Cohn <mike@...> wrote:> If the result of the sprint is given> to users to at least experiment with then > they'll find it at the end of the> sprint so it goes undetected for 30 days or > so at most.

I would say that the Scrum practices will ensurethat none of the above _ever_ happens,

Good points, Hal. I think Scrum and XP do a better job of bringing these types of things to light than anything else I ve read about, seen or tried. I just

Message 16 of 25
, Apr 28, 2003

0 Attachment

Good points, Hal.

I think Scrum and XP do a better job of
bringing these types of things to light than anything else I’ve read
about, seen or tried. I just wanted to make the point that I can always hide
some deficiency for a little while—either because I’m destructive
or just embarrassed to bring it up.

You’re point about “continue
to engage” is a good one. I think a lot of agile projects overlook the
role of a project manager in keeping a team motivated, having ownership and
moving forward. One of my favorite books is “Teamwork” by Larson
and LaFasto. They identify 8 things necessary to having a successful team,
based on their research into all sorts of successful teams from a variety of
domains. Number one on their list is a “clear, elevating goal.” The
goal has to be something easily understood (“clear”) but also has
to be motivating—“finish by June 30 or I’ll fire you”
doesn’t qualify. An obvious clear, elevating goal was Kennedy’s “a
man on the moon by the end of the decade.” From the projects I’ve
worked on I’d say that the lack of a clear, elevating goal is probably
the best indicator that a project will fail. If the goal is clear and elevating
teams will take the ownership you describe and move mountains. Unfortunately, I’d
say the majority of projects (at least that I’ve seen, and maybe I’m
just cursed) do not have clear, elevating goals.

So all of what you say seems possible -- for some
period of time. And it is true that people lie, shade the truth, and
leave out important details. If we are talking about criminal behavior --
intent to deceive for some personal gain -- then we know what to do: get rid of
the team member. But I have found people behave this way out of
frustration that work isn't proceeding the way they want, embarassment that
they can't perform as expected, resignation with some aspect of the project,
etc. The only thing I've seen to overcome the power of those moods is
having ownership in the
successful outcome of the project.

Some people argue that of course my team members are
committed to the success of the project. However the behaviors
described in this thread are all too familiar. We can't say that people
demonstrating these behaviors take full ownership in success. It is the
project leader's responsibility to continue to engage team members as owners of
the promise to the customer. I say 'continue to engage' because the
nature of our lives is that other things are always coming up -- the school
play, the soccer match, our spouse's birthday, a more challenging assignment, a
redirection of the project, abandonning code, etc. -- competing with the
big commitments we've made. Without explict acts of re-engaging
ownership individuals and the team will eventually drift from their commitment.

I've been directly involved with 30-40 software
projects. None were done on an agile basis. For the last 4 years I
have managed and consulted to organizations doing projects on a lean
basis. It seems to me the combination of Scrum practices with ongoing
care for ownership will allow teams to avoid the isues identified.

Mike Cohn <mike@...> wrote:

I disagree but only in the subtle cases. If I'm
charged with writing a pieceof code and work with a pair to do it we may get
it to a certain point thatmy pair thinks it's done and it appears done
because it passes QA's tests.Yet, I'm aware of some subtle times when it will
fail and I don't bring themup because I don't want to rewrite that area. For
example, long ago Iremember writing code for an interactive voice
response system and therewere lots of intricate rules about when to add
various elements to the phonenumber (country code, area, 1+0, etc.). Most
international numbers followedthe same rules. I don't remember the specifics but
there were a fewoccasions where international dialing was a little
different. If I had beenpairing with someone I could have hidden my
knowledge of that and QAwouldn't have found it either. It is possible to
hide some unfinished work.I don't think any process can prevent this type of
behavior.

--- Mike Cohn <mike@...>
wrote:> The daily scrum helps protect against this.
Even > if I don't want to admit I'm having troubles > with task A it is hard for me to hide that
for long.

True, but I would argue that the combination of Daily Scrums, Pairing, Continuous Integration, Daily Build, Unit Tests, and Acceptance Tests, make it _impossible_ to hide any troubles
whatsoever.

--- Mike Cohn
<mike@...> wrote:> a) Either I stay on it for a long time and > someone in a Scrum meeting asks,
"Weren't you > supposed to be done with that 3 weeks
ago?"

In Scr um you can't lie. If you say you weresupposed to be done 3 weeks ago, the team willnotice within the first 24 hrs. and the teamwill react _immediately_ to it because your pairwill notice that you didn't work on this, yourunit tests won't pass, the build won't have thefunctionality, the customer will notice he/shecan't acceptance test it, etc.

So it will be _very hard_ to go unnoticed.

But that's the whole premise of Scrum -- nothing will go unmonitored for extended periods of timei.e. (> t 24).

This will not happen in Scrum because _everyone_will notice the expected functionality:

* is not passing unit tests* is not in configuration management* is not in the build* can't be acceptance tested* etc.

_even_ if it is reported as done in the Daily
Scrums.

--- Mike Cohn
<mike@...> wrote:> Whoever is on the team doing testing will > notice this or it will come up at the sprint > review.

In Scrum _everyone_ will be doing testing everyday:

- the developers will be doing unit testing - the developers will be doing automated acceptance testing - the customer/stakeholders will be doing
automated/ non-automated acceptance
testing and giving continuous feedback

--- Mike Cohn
<mike@...> wrote:> c) Or, I code something that works in 95% of > the cases and is good enough to pass tests ..

Hopefully something working at 95% won't pass 100% of the tests ;-) -- or else we might have thewrong tests.

--- Mike Cohn <mike@...>
wrote:> but as soon as a real user gets it they'll & gt; start to find all the problems and
fixing them > will be a major effort.

--- Mike Cohn
<mike@...> wrote:> If the result of the sprint is given> to users to at least experiment with then > they'll find it at the end of the> sprint so it goes undetected for 30 days or > so at most.

I would say that the Scrum practices will ensurethat none of the above _ever_ happens,

I like Ron s articulation of the rule, Seek help the moment it might improve your situation. I ve written about my frustration with a programmer who

Message 17 of 25
, Apr 28, 2003

0 Attachment

I like Ron's articulation of the rule, "Seek help the moment it might improve your situation." I've written about my frustration with a programmer who operated to the rule "Seek help only after you've consumed all the time budgeted." He would say he wanted a 'fair shot' at solving the problem. He wasn't nearly as smart as he thought he was, consequently he repeatedly introduced delays (and costs) in the project when he didn't check-in his code as expected or when his function wasn't ready for others. The team eventually turned this guy around when they got him to understand he put the whole project at risk. They were not able to express the rule as cleanly as stated below. Their rule was "Seek help when your promise is at risk." Of course that took making the assessment of risk. I like this one better.

Ron Jeffries <ronjeffries@...> wrote:

On Monday, April 28, 2003, at 8:18:59 AM, Dean Goodmanson wrote:

> In light of "Seek help only when you've exhausted all> your resources", that statement was something I'm glad> to see articulated.

I wonder whether "seek help the moment it might improve your situation"would be a better rule to live by.

It undoubtedly would but that is so hard to get people to do. I try to encourage people to get to the point where they feel they ve asked for help too early as

Message 18 of 25
, Apr 28, 2003

0 Attachment

It undoubtedly would but that is so hard to get people to do. I try to
encourage people to get to the point where they feel they've asked for help
too early as often as they ask for help too late. (Rather than 1% too early,
99% too late, which is more common for too many developers.)

> I'm wondering about the experience people have with pair programming. I
would guess there
> would be less of a problem 'raising the flag'. First, with two people on
a task they would
> be more likely to work through the problem. Second, with two people each
individual is
> already getting help. Asking for some more time or more help looks like a
small step for the
> pair to take. What is your experience??

As I become more and more familiar with a particular pair, I'm more and
more ready to express confusion or ignorance the moment I notice it. I get
more and more used to his gentle reminders "semicolon", or "do we need a
test".

And I get more and more comfortable expressing my confusion and ignorance
even with a new pair. And even in other places where I might feel the need
to seem like I know everything. <humor type="dubious">Of course, since I do
know /nearly/ everything, this skill is of limited use, but I was thinking
that for actual mortals, it could be really good.</humor>

But seriously. Help is good. The more I get, the more I give, the better I
do.

Ron Jeffries
www.XProgramming.com
No one expects the Spanish Inquisition ...

This pair programming thing has tremendous potential as a model for design and engineering work of all types. As we near deadlines my partner and I default to

Message 20 of 25
, Apr 28, 2003

0 Attachment

This pair programming thing has tremendous potential as a model for design and engineering work of all types. As we near deadlines my partner and I default to it as we prepare proposals to clients. I see architects skip the usual draw > redline > re-draw process for a paired approach when they are in the field working out an issue of constructability.

There may be an opportunity for the project coach. <humor type="sarcasm">If they would just do what I know is good for them, then the project would be successful.</humor> Pair coaching team members might uncover what could work.

Hal

Ron Jeffries <ronjeffries@...> wrote:

On Monday, April 28, 2003, at 8:48:41 AM, Hal Macomber wrote:

> I'm wondering about the experience people have with pair programming. I would guess there> would be less of a problem 'raising the flag'. First, with two people on a task they would> be more likely to work through the problem. Second, with two people each individual is> already getting help. Asking for some more time or more help looks like a small step for the> pair to take. What is your experience??

As I become more and more familiar with a particular pair, I'm more andmore ready to express confusion or ignorance the moment I notice it. I getmore and more used to his gentle reminders "semicolon", or "do we need atest".

And I get more and more comfortable expressing my confusion and ignoranceeven with a new pair. And even in other places where I might feel the needto seem like I know everything. <humor type="dubious">Of course, since I doknow /nearly/ everything, this skill is of limited use, but I was thinkingthat for actual mortals, it could be really good.</humor>

But seriously. Help is good. The more I get, the more I give, the better Ido.

Musings - What are some of the things that lead a developer to not seek help the moment it might improve the situation? 1. Poor sprint/project goal

Message 21 of 25
, Apr 28, 2003

0 Attachment

Musings -

What are some of the things that lead a developer to not "seek help
the moment it might improve the situation?"

1. Poor sprint/project goal alignment - This is the thing I struggle
with more than anyother. Some developers want to build the perfect
system. I don't want them to. I want them to build a very solid
system as quickly as possible. It is stunningly hard to get everyone
aligned. It is possible for someone to spend too much time trying to
solve a problem because they are working with their head down, just
trying to solve the problem and not seeing the bigger picture.

2. Incompetence - There is only one solution.

3. Fear - Big problem. Cultural issues can really effect this. If
I tell a team, give me what you can by Date X and I can live with
that, they often struggle with fear that on Date X they will get
blasted for not getting everything done. Consequently, they work to
hard on low value, hard problems. Only time and consistant
management values can solve this.

4. Inxeperience with seeking help early. Pair programming would
probably help, but we don't do it. Daily standups do help. Having
developers own tasks as a group as opposed to being assigned tasks by
someone else may help.

might improve your situation." I've written about my frustration
with a programmer who operated to the rule "Seek help only after
you've consumed all the time budgeted." He would say he wanted
a 'fair shot' at solving the problem. He wasn't nearly as smart as
he thought he was, consequently he repeatedly introduced delays (and
costs) in the project when he didn't check-in his code as expected or
when his function wasn't ready for others. The team eventually
turned this guy around when they got him to understand he put the
whole project at risk. They were not able to express the rule as
cleanly as stated below. Their rule was "Seek help when your promise
is at risk." Of course that took making the assessment of risk. I
like this one better.

> Ron Jeffries <ronjeffries@a...> wrote:On Monday, April 28, 2003,

at 8:18:59 AM, Dean Goodmanson wrote:

>
> > In light of "Seek help only when you've exhausted all
> > your resources", that statement was something I'm glad
> > to see articulated.
>
> I wonder whether "seek help the moment it might improve your

situation"

> would be a better rule to live by.
>
> Ron Jeffries
> www.XProgramming.com
> It is a bad plan that admits of no modifications. -- Publius Syrus

The road to Mastery is long -- especially from where I seem to be standing
at the moment. ;->

Ron Jeffries
www.XProgramming.com
Knowledge must come through action;
you can have no test which is not fanciful, save by trial. -- Sophocles

Mike Cohn

On #1, it s been my experience that this is almost universal with recent college graduates. My theory is that they are used to every professor grading them

Message 23 of 25
, Apr 28, 2003

0 Attachment

On #1, it's been my experience that this is almost universal with recent
college graduates. My theory is that they are used to every professor
grading them independently. I can't go to my Physics prof and say "I was
busy with Chemistry homework all weekend and did a great job on that so
please factor that in when you grade me." Each professor evaluates them
independently so they are accustomed to having to do A quality work for
each. That carries over into how they view their work for a manager. But,
you're right--not every task on a project needs A-quality work. Some things
just need to be done. (They can't, perhaps, be done poorly; but doing them
overly well is unnecessary.) I used to work with someone who frequently
said, "The perfect is the enemy of the good," which is a good way to think
about it.

As for #3, the team will usually respond better (take more ownership) if
they pick what they do by the date, rather than it being told to them. But,
of course, that's fundamental to Scrum.

What are some of the things that lead a developer to not "seek help
the moment it might improve the situation?"

1. Poor sprint/project goal alignment - This is the thing I struggle
with more than anyother. Some developers want to build the perfect
system. I don't want them to. I want them to build a very solid
system as quickly as possible. It is stunningly hard to get everyone
aligned. It is possible for someone to spend too much time trying to
solve a problem because they are working with their head down, just
trying to solve the problem and not seeing the bigger picture.

2. Incompetence - There is only one solution.

3. Fear - Big problem. Cultural issues can really effect this. If
I tell a team, give me what you can by Date X and I can live with
that, they often struggle with fear that on Date X they will get
blasted for not getting everything done. Consequently, they work to
hard on low value, hard problems. Only time and consistant
management values can solve this.

4. Inxeperience with seeking help early. Pair programming would
probably help, but we don't do it. Daily standups do help. Having
developers own tasks as a group as opposed to being assigned tasks by
someone else may help.

might improve your situation." I've written about my frustration
with a programmer who operated to the rule "Seek help only after
you've consumed all the time budgeted." He would say he wanted
a 'fair shot' at solving the problem. He wasn't nearly as smart as
he thought he was, consequently he repeatedly introduced delays (and
costs) in the project when he didn't check-in his code as expected or
when his function wasn't ready for others. The team eventually
turned this guy around when they got him to understand he put the
whole project at risk. They were not able to express the rule as
cleanly as stated below. Their rule was "Seek help when your promise
is at risk." Of course that took making the assessment of risk. I
like this one better.

> Ron Jeffries <ronjeffries@a...> wrote:On Monday, April 28, 2003,

at 8:18:59 AM, Dean Goodmanson wrote:

>
> > In light of "Seek help only when you've exhausted all
> > your resources", that statement was something I'm glad
> > to see articulated.
>
> I wonder whether "seek help the moment it might improve your

situation"

> would be a better rule to live by.
>
> Ron Jeffries
> www.XProgramming.com
> It is a bad plan that admits of no modifications. -- Publius Syrus