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

312RE: [scrumdevelopment] Middle-up-down vs. bottom-up

Expand Messages
  • Jonas Bengtsson
    May 3, 2002

      It seems like we're on the same page. Perhaps one could say that there is an
      emphasis on both team and individual - the team commits to the work and is
      responsible to make it happen (on a Sprint level) and the individual
      commits/is responsible on a daily basis. Do that sound reasonable? What I
      meant by emphasis on team was that it's not individualistic but the team
      work/spirit/etc play a major role.

      I think I agree about that the "typical aspects" have a big perceptage of
      the work. But how do you deal with that? If most work is routine how do you
      keep the motivation high? I, for one, need challanges every now and then. I
      guess I tackle the problem by making it into a challange, e.g. by completing
      the work faster than I've done before, or perhaps (do I dare to say :-) by
      adding small features.

      Another question, how important is the ScrumMaster? (both for the
      "knowledge-creation" and for the success of the project in general) I guess
      it differs quite much from project to project. Is it possible that s/he
      becomes less important as the team gets more jelled? Are there any
      self-directing Scrum teams out there?


      -----Original Message-----
      From: Mike Cohn [mailto:mike@...]
      Sent: Friday, May 03, 2002 10:13 PM
      To: scrumdevelopment@yahoogroups.com
      Subject: RE: [scrumdevelopment] Middle-up-down vs. bottom-up

      I guess I would have considered Scrum to be a process that puts emphasis on
      the individual but does so by putting a team framework in place to support
      that individual. I think most individuals working on Scrum projects would
      consider it very liberating from the perspective of personal productivity.

      As for knowledge being created by individuals who "operate as independent
      and separate actors" I'd largely agree with that. But-I'd also suggest that
      the bulk of most software projects are not about knowledge creation. Drucker
      's "knowledge worker" term doesn't have to mean the individual is always
      creating knowledge; it could mean that the worker uses his knowledge. For a
      typical software project there is knowledge created during the activities
      where truly new thought is occurring but I don't think knowledge is created
      when fairly typical aspects of the system are being coded---and most systems
      have a big percentage of this type of work.

      So, while individuals create knowledge the application of that knowledge is
      put to practical use through a team. Scrum works (in my opinion and Mike
      Beedle seems like the one who'd know more about this topic) because if
      allows for individual creativity but always with the framework of a team
      around it. If I go off on a programming tangent that may or may not pay off
      (i.e., creating knowledge) I can do that because I know that if my detour
      doesn't work the rest of the team will help pick up on tasks I got behind

    • Show all 11 messages in this topic