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

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

Expand Messages
  • Mike Cohn
    May 3, 2002

      Yes, I think we’re on the same page on this.

       

      I guess I didn’t consider the work to be routine, just not knowledge-creating. I’m thinking of a project I’m working with right now where one of the programmers is writing a simple user administration program to accompany the main program (to allow creation of new users, delete existing users, etc.). Everyone has written something similar so it’s not creating new knowledge but it isn’t exactly routine because he hasn’t done it dozens of previous times. Every programmer (person in general) finds his challenges different ways so I generally don’t give a programmer a challenge of “do this routine task faster than you’ve done it before” because not all programmers like that type of challenge (another may prefer to do it is less memory, etc.). In true Scrum manner that type of decision is best left to each individual.

       

      The Scrum Master is vital. I’m not sure if the role becomes less important with jelled teams but the role can become much less distinct. As the team comes together there is less need for the orchestrating activities of a Scrum Master and so I’ve found it easier for one of the programmers to do the job after having watched it happen for awhile. I’m thinking about one team I’m working with—there are 6 people on the team and I’ve worked with 3 of them in various capacities for much of the last 8 years so we obviously have a history together. We started with a Scrum-like process way back then and have evolved it as we learned or as Ken, Mike and others published on the topic. So the 3 on this team are pretty familiar with what they need to do and my duties as a scrum master to them are very simple relative to what other teams need.

       

      -----Original Message-----
      From: Jonas Bengtsson [mailto:jonas.b@...]
      Sent: Friday, May 03, 2002 3:34 PM
      To: scrumdevelopment@yahoogroups.com
      Subject: RE: [scrumdevelopment] Middle-up-down vs. bottom-up

       

      Mike,

      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?

      Jonas

      -----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
      on.

      --Mike



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


      Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
    • Show all 11 messages in this topic