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

RE: [scrumdevelopment] Culture clash - was - Re: monitoring bad SCRUM

Expand Messages
  • 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 1 of 25 , Apr 28 10:22 AM
      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.


      -----Original Message-----
      From: John Gilman [mailto:jpgilman@...]
      Sent: Monday, April 28, 2003 11:02 AM
      To: scrumdevelopment@yahoogroups.com
      Subject: [scrumdevelopment] Culture clash - was - Re: monitoring bad SCRUM

      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.


      --- In scrumdevelopment@yahoogroups.com, Hal Macomber <hal@h...>
      > 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@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.
      > Ron Jeffries
      > www.XProgramming.com
      > It is a bad plan that admits of no modifications. -- Publius Syrus
      (ca. 42 BCE)
      > [input] Subscribe to Reforming Project Management
      > Enter your email address:
      > [input] [input]
      > Don't miss a posting! Forward to a friend.

      To Post a message, send it to: scrumdevelopment@...
      To Unsubscribe, send a blank message to:

      Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
    Your message has been successfully submitted and would be delivered to recipients shortly.