RE: [scrumdevelopment] Culture clash - was - Re: monitoring bad SCRUM
- 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
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.
From: John Gilman [mailto:jpgilman@...]
Sent: Monday, April 28, 2003 11:02 AM
Subject: [scrumdevelopment] Culture clash - was - Re: monitoring bad 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.
--- In firstname.lastname@example.org, Hal Macomber <hal@h...>
>might improve your situation." I've written about my frustration
> I like Ron's articulation of the rule, "Seek help the moment it
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
> would be a better rule to live by.(ca. 42 BCE)
> Ron Jeffries
> It is a bad plan that admits of no modifications. -- Publius Syrus
>To Post a message, send it to: scrumdevelopment@...
> [input] Subscribe to Reforming Project Management
> Enter your email address:
> [input] [input]
> Don't miss a posting! Forward to a friend.
To Unsubscribe, send a blank message to:
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/