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

Re: [scrumdevelopment] Re: My head is full Can I go home now? // Shock Therapy

Expand Messages
  • Mark Graybill
    ... From: Tobias Mayer To: scrumdevelopment@yahoogroups.com Sent: Saturday, April 11, 2009 3:23 PM Subject: [scrumdevelopment] Re: My head is full Can I go
    Message 1 of 68 , Apr 16, 2009
    • 0 Attachment
      ----- Original Message -----
      From: Tobias Mayer
      To: scrumdevelopment@yahoogroups.com
      Sent: Saturday, April 11, 2009 3:23 PM
      Subject: [scrumdevelopment] Re: My head is full Can I go home now? // Shock
      Therapy

      > Writing software is not like martial arts. Writing software is a creative
      > endeavor, where new ideas and behaviors need to be embraced.
      > Learning a martial art is about following of a set of rules, and not
      > thinking for yourself. It is a flawed analogy.

      The analogy in the use you make here is flawed, but not in its original use.

      The analogy was comparing simple ideas of progression and the use of
      mentoring, not comparing two totally unrelated fields. The analogy leads to
      the use of creativity as a master to address contexts not conforming to the
      "rules" (e.g. specific katas), and to learn as you go.

      > The people we work with usually know a lot more about how to do
      > their work than we do. Our job is to simply hold up a mirror, to
      > guide, not to teach; it is to encourage, to play, to bring out what is
      > good in people, teams and organizations, not to forcefully impose a
      > new process.

      People can be very good at doing *their* work. But even the experts may not
      be expert at doing their work in collaboration with others. By nature we
      perceive and behave in ways that detract from effective software development
      in groups. This leads to what you say about leading and mentoring, but it
      does included teaching. Teaching/mentoring each other and the corollary,
      learning from each other is a fundamental aspect of what is expected of
      software developers operating in a team development effort. In fact, the
      principle of learning/teaching from each other is in stark conflict with
      competition, which pervades - infests our field.

      Just to look back, computer science has its roots in mathematics, which is
      more individualistic and competitive than what corporate software
      development demands. So experts may know how to do their job well by
      themselves, on say a one-man project, but that expertise may or may not
      accomodate the involvement of other people. Moreover, when a paradigm shift
      is warranted, typically the more one is an expert, the more one has to
      unlearn to make the shift. Stealing an appropriate concept from a Brian
      Greene quote, sometimes a slight shift in perspective makes all the
      difference in whether a breakthrough is made or not made.

      But your general point is valid. To illustrate my agreement with it, after
      a major career goal of mine, I took the next step so to focus on the
      building blocks for my next major goal. That included (among other things)
      I go to work for a particular place where out of over three dozen
      organizations I've worked or consulted in, change is the hardest to make.
      Simply put, shock, compulsion or otherwise any coercive smell behind some
      change is sure to kill it. Due to organizational and HR policies, and its
      size, this organization represents the most stubborn challenge for those
      aspiring to be change agents.

      So my approach, off the top of my head, will include some dependency in
      building understanding about the change and making individuals players in
      the change process. There are also certain leadership qualities that are
      necessary as well.

      So, point generlaly made. :)
    • Mark Graybill
      ... From: Tobias Mayer To: scrumdevelopment@yahoogroups.com Sent: Saturday, April 11, 2009 3:23 PM Subject: [scrumdevelopment] Re: My head is full Can I go
      Message 68 of 68 , Apr 16, 2009
      • 0 Attachment
        ----- Original Message -----
        From: Tobias Mayer
        To: scrumdevelopment@yahoogroups.com
        Sent: Saturday, April 11, 2009 3:23 PM
        Subject: [scrumdevelopment] Re: My head is full Can I go home now? // Shock
        Therapy

        > Writing software is not like martial arts. Writing software is a creative
        > endeavor, where new ideas and behaviors need to be embraced.
        > Learning a martial art is about following of a set of rules, and not
        > thinking for yourself. It is a flawed analogy.

        The analogy in the use you make here is flawed, but not in its original use.

        The analogy was comparing simple ideas of progression and the use of
        mentoring, not comparing two totally unrelated fields. The analogy leads to
        the use of creativity as a master to address contexts not conforming to the
        "rules" (e.g. specific katas), and to learn as you go.

        > The people we work with usually know a lot more about how to do
        > their work than we do. Our job is to simply hold up a mirror, to
        > guide, not to teach; it is to encourage, to play, to bring out what is
        > good in people, teams and organizations, not to forcefully impose a
        > new process.

        People can be very good at doing *their* work. But even the experts may not
        be expert at doing their work in collaboration with others. By nature we
        perceive and behave in ways that detract from effective software development
        in groups. This leads to what you say about leading and mentoring, but it
        does included teaching. Teaching/mentoring each other and the corollary,
        learning from each other is a fundamental aspect of what is expected of
        software developers operating in a team development effort. In fact, the
        principle of learning/teaching from each other is in stark conflict with
        competition, which pervades - infests our field.

        Just to look back, computer science has its roots in mathematics, which is
        more individualistic and competitive than what corporate software
        development demands. So experts may know how to do their job well by
        themselves, on say a one-man project, but that expertise may or may not
        accomodate the involvement of other people. Moreover, when a paradigm shift
        is warranted, typically the more one is an expert, the more one has to
        unlearn to make the shift. Stealing an appropriate concept from a Brian
        Greene quote, sometimes a slight shift in perspective makes all the
        difference in whether a breakthrough is made or not made.

        But your general point is valid. To illustrate my agreement with it, after
        a major career goal of mine, I took the next step so to focus on the
        building blocks for my next major goal. That included (among other things)
        I go to work for a particular place where out of over three dozen
        organizations I've worked or consulted in, change is the hardest to make.
        Simply put, shock, compulsion or otherwise any coercive smell behind some
        change is sure to kill it. Due to organizational and HR policies, and its
        size, this organization represents the most stubborn challenge for those
        aspiring to be change agents.

        So my approach, off the top of my head, will include some dependency in
        building understanding about the change and making individuals players in
        the change process. There are also certain leadership qualities that are
        necessary as well.

        So, point generlaly made. :)
      Your message has been successfully submitted and would be delivered to recipients shortly.