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

Re: [scrumdevelopment] Blog post for discussion

Expand Messages
  • Robin Dymond
    Hi Roy, I completed Electrical Engineering in 1990 and always wondered about why some of these skills were not taught when I was in school. But then I thought
    Message 1 of 5 , Aug 2, 2007
    • 0 Attachment
      Hi Roy,

      I completed Electrical Engineering in 1990 and always wondered about why some of these skills were not taught when I was in school. But then I thought about the professors :) and the answer was clear.

      I think there is a clear Agile/XP curriculum, we spend most of our time practicing, thinking about and teaching it. If today there was a school that could produce perfect Agile/XP developers, they would still work in an environment with status quo management. The way businesses are run needs to change as badly as dev practices.

      Someone who is doing something about this is Frank Mauer and Grigori Melnick at University of Calgary.

      cheers,
      Robin.

      On 8/1/07, Roy Morien <roymorien@...> wrote:

      I don't know about imprinting, but I do know that most people are more comfortable using the tools that they are familiar with. This has been the 'curse ' of the IT industry from time immemorial (actually, from time memorial, because there are still many of us from 'the olden days' of the 1980's and early 1990's who remember this situation.
       
      In 1993 I published an academic paper entitled "Educating Information Systems Professionals: The Tertiary Educational Challenge" at a conference in Australia. The following quotable quotes were given in that paper.

      •                   IST practitioners have often been conservative and obstructionist in their work (Nosek & Sherr, 1983;   Abbey, 1984)
      •                   There has been a continued reluctance for IST practitioners to adopt new technologies, for a variety of reasons (Nosek & Sherr, 1983;   Abbey, 1984;  Khosrowpour & Lanasa, 1989)
      •                   Experience and competence at current techniques and practices have been burdens for practitioners when faced with the need to update their skills. (Earl, 1987; Khosrowpour & Lanasa, 1989; McLanahan & Perotti, 1991)
      •                   The often narrow, technical outlook of many IST practitioners is not appreciated by managers, and more liberal   education is considered preferable. (Friedman & Greenbaum, 1984; Datamation, 1987;)
      •                   The methods and practices adopted and used by IST practitioners are rigid, bureaucratic and unacceptable to many users and clients. (Arthur, 1992)
      •               The criteria of success for IST practitioners are far removed from that applied by the users of the information systems.   Whereas the IST practitioner sees a successful outcome in terms of technical efficiencies, and technical successes, these frequently fail to include issues of usefulness, relevance, effectiveness, or business value-added, which are the criteria of success applied by the administrative and managerial personnel in the organisation.   (Urquhart, 1993)
      •                   Some information system development methods  in use within the industry are far too rigid and inflexible, and are even described as dangerous; preventing the development of effective, timely, information systems (James, 1991; Urquhart, 1993;)
      As you can see, these are quotes from papers published as far back as 1983. So this reluctance to adopt new IDE's or new methods has been commented upon and rued for over 20 years.
       
      My theory is that most IT practitioners are never given any good education in management principles, in 'change management' and general business principles relating to matters of productivity.
       
      Excerpting again from my paper ...
       

      The I/S Analyzer [1988] states that the IST practitioner now needs skills in the following areas: Technical Skills, Human Resource Skills, Business Knowledge, Transitional Skills. It is this latter which holds particular interest. To quote the publication,

       

      'Transitional skills are deemed necessary because systems professionals face drastic changes, brought about by business changes and more flexible and easy-to-use technology'.

       

      'Transitional training will emphasize understanding and effectively dealing with change, migrating to new technologies, learning to work closely with people in other areas of the company, understanding organisational behaviour, and broadening technical knowledge.'

       

      Urquhart [1993] concludes that

       

      'Given the documented failure of projects and evidence of communication problems in the software definition stage, ... strengthening developers' personal skills would make at least as a valuable a contribution to project success as the adoption of system development methodologies'.

       

      Can anyone tell me of their college or university undergraduate, and graduate, courses where these variety of 'soft' skills are taught? Even after having been a university teaching academic in an IS / IT school for over 20 years, I cannot point to a single course that includes these skills ... obviously my view cannot be especially universal.
       
      And I would dearly love to be able to compile a list of colleges and universities who actually teach any variety of agile development and agile project management in their IS / IT / CS / MIS courses. I would be very happy to receive any such information.
       
      Regards,
      Roy Morien

       

       



      To: extremeprogramming@yahoogroups.com; scrumdevelopment@yahoogroups.com
      From: mowat27@...
      Date: Wed, 1 Aug 2007 12:10:43 +0100
      Subject: [scrumdevelopment] Blog post for discussion

      Hi all,
       
      I just read this article on a blog I subscribe to and I think it might interest this group...
       
       
      In summary, if has been found that animals "imprint on the first creature they see shortly after birth" and the author of the post argues that developers have a similar reaction to trying new tools.  The example used is that we might be reluctant to try a new IDE because we are used to the one we have always used and are still trying to maximise our productivity using it.
       
      I believe we often see a similar effect when trying to get an organisation to try new Agile ideas - no matter how hard we work to explain the benefits.
       
      Thoughts?
       
      Cheers
       
      Adrian
       
       




      Get news, entertainment and everything you care about at Live.com. Check it out!

    • Roy Morien
      Nice to have a response to my email, Robin. I am a bit dubious about your comment but then I thought about the professors and the answer was clear :) Having
      Message 2 of 5 , Aug 2, 2007
      • 0 Attachment
        Nice to have a response to my email, Robin. I am a bit dubious about your comment "but then I thought about the professors and the answer was clear" :)  Having been one of those professors for a number of years, I could take exception :)
         
        BUT ... yes ... you're right. The problem is, it is not only the 'old fogie professors' who are to blame. Many new and young academic staff members, no doubt well qualified with their PhDs etc are really just recycled 'top' students, who proceed to teach what they learned, thus propagating the 'ignorance cycle'. That is understandable, I guess ... you cannot teach what you don't know, and you don't know it if your were not taught it. I fought for literally 20 years to have contemporary topics such as software prototyping, rapid application development etc., and latterly agile methods ... to no avail. Even though I was one of the longest standing members of the faculty, and therefore considered 'old and probably conservative and dull' by administrative and academic managers, I did not see any of the young up and coming academics being very contemporary in their SA & D thinking.  I am 60, by the way :)
         
        Perhaps it was my original education and training in accounting, management and business law that formed my views, prior to entering the world of systems development, which has that strange ambiguity ... to again quote my 1993 paper, the opening paragraphs :
         

        A strange and puzzling contradiction has been reported in the computer press and literature over the last 10 years. On the one hand, the information systems and technology (IST) industry is perceived by many as dominated by an unrelenting tide of innovation and change. At the same time, the practitioners involved in that industry are frequently perceived as being conservative and obstructionist, unwilling (or unable) to ensure that their skills remain current and useful.

         

        Two major streams of concern and experience are traced; one being that of constant warnings that IST professionals are professionals at risk, unless major changes in attitude, professional development, and reskilling come about. The other is the doleful record of substantial failures of information systems, resulting in hundreds of millions of dollars worth of development being discarded, often accompanied by significant business losses.

         

        This grim record of conservatism, obstructionist attitudes, vast waste of corporate resources, and failure to maintain forward looking and professional attitudes, is taken to what is seen as the logical conclusion for many practitioners; redundancy, unemployment, career disasters, as reported in the computer press.

        At that time there was a major mood that was pro 'end user development' because of the attitudes and failures of IT professionals. System development was more an adversary activity than a cooperative activity, and users were geting sick of it, and turning towards the (apparently) easy to use development tools.
         
        Yes, I have some papers written by Mauer and Melnik.
         
        Anyway, keep in touch. I like to know who is doing what to whom in the software development industry :)
         
        Kind regards,
        Roy Morien




        To: scrumdevelopment@yahoogroups.com
        From: robin.dymond@...
        Date: Thu, 2 Aug 2007 22:35:24 -0400
        Subject: Re: [scrumdevelopment] Blog post for discussion

        Hi Roy,

        I completed Electrical Engineering in 1990 and always wondered about why some of these skills were not taught when I was in school. But then I thought about the professors :) and the answer was clear.

        I think there is a clear Agile/XP curriculum, we spend most of our time practicing, thinking about and teaching it. If today there was a school that could produce perfect Agile/XP developers, they would still work in an environment with status quo management. The way businesses are run needs to change as badly as dev practices.

        Someone who is doing something about this is Frank Mauer and Grigori Melnick at University of Calgary.

        cheers,
        Robin.

        On 8/1/07, Roy Morien <roymorien@hotmail. com> wrote:

        I don't know about imprinting, but I do know that most people are more comfortable using the tools that they are familiar with. This has been the 'curse ' of the IT industry from time immemorial (actually, from time memorial, because there are still many of us from 'the olden days' of the 1980's and early 1990's who remember this situation.
         
        In 1993 I published an academic paper entitled "Educating Information Systems Professionals: The Tertiary Educational Challenge" at a conference in Australia. The following quotable quotes were given in that paper.

        •                   IST practitioners have often been conservative and obstructionist in their work (Nosek & Sherr, 1983;   Abbey, 1984)
        •                   There has been a continued reluctance for IST practitioners to adopt new technologies, for a variety of reasons (Nosek & Sherr, 1983;   Abbey, 1984;  Khosrowpour & Lanasa, 1989)
        •                   Experience and competence at current techniques and practices have been burdens for practitioners when faced with the need to update their skills. (Earl, 1987; Khosrowpour & Lanasa, 1989; McLanahan & Perotti, 1991)
        •                   The often narrow, technical outlook of many IST practitioners is not appreciated by managers, and more liberal   education is considered preferable. (Friedman & Greenbaum, 1984; Datamation, 1987;)
        •                   The methods and practices adopted and used by IST practitioners are rigid, bureaucratic and unacceptable to many users and clients. (Arthur, 1992)
        •               The criteria of success for IST practitioners are far removed from that applied by the users of the information systems.   Whereas the IST practitioner sees a successful outcome in terms of technical efficiencies, and technical successes, these frequently fail to include issues of usefulness, relevance, effectiveness, or business value-added, which are the criteria of success applied by the administrative and managerial personnel in the organisation.   (Urquhart, 1993)
        •                   Some information system development methods  in use within the industry are far too rigid and inflexible, and are even described as dangerous; preventing the development of effective, timely, information systems (James, 1991; Urquhart, 1993;)
        As you can see, these are quotes from papers published as far back as 1983. So this reluctance to adopt new IDE's or new methods has been commented upon and rued for over 20 years.
         
        My theory is that most IT practitioners are never given any good education in management principles, in 'change management' and general business principles relating to matters of productivity.
         
        Excerpting again from my paper ...
         
        The I/S Analyzer [1988] states that the IST practitioner now needs skills in the following areas: Technical Skills, Human Resource Skills, Business Knowledge, Transitional Skills. It is this latter which holds particular interest. To quote the publication,
         
        'Transitional skills are deemed necessary because systems professionals face drastic changes, brought about by business changes and more flexible and easy-to-use technology'.
         
        'Transitional training will emphasize understanding and effectively dealing with change, migrating to new technologies, learning to work closely with people in other areas of the company, understanding organisational behaviour, and broadening technical knowledge.'
         
        Urquhart [1993] concludes that
         
        'Given the documented failure of projects and evidence of communication problems in the software definition stage, ... strengthening developers' personal skills would make at least as a valuable a contribution to project success as the adoption of system development methodologies'.
         
        Can anyone tell me of their college or university undergraduate, and graduate, courses where these variety of 'soft' skills are taught? Even after having been a university teaching academic in an IS / IT school for over 20 years, I cannot point to a single course that includes these skills ... obviously my view cannot be especially universal.
         
        And I would dearly love to be able to compile a list of colleges and universities who actually teach any variety of agile development and agile project management in their IS / IT / CS / MIS courses. I would be very happy to receive any such information.
         
        Regards,
        Roy Morien
         

         



        To: extremeprogramming@ yahoogroups. com; scrumdevelopment@ yahoogroups. com
        From: mowat27@googlemail. com
        Date: Wed, 1 Aug 2007 12:10:43 +0100
        Subject: [scrumdevelopment] Blog post for discussion

        Hi all,
         
        I just read this article on a blog I subscribe to and I think it might interest this group...
         
         
        In summary, if has been found that animals "imprint on the first creature they see shortly after birth" and the author of the post argues that developers have a similar reaction to trying new tools.  The example used is that we might be reluctant to try a new IDE because we are used to the one we have always used and are still trying to maximise our productivity using it.
         
        I believe we often see a similar effect when trying to get an organisation to try new Agile ideas - no matter how hard we work to explain the benefits.
         
        Thoughts?
         
        Cheers
         
        Adrian
         
         




        Get news, entertainment and everything you care about at Live.com. Check it out!




        Get news, entertainment and everything you care about at Live.com. Check it out!
      • derek.wade
        ... creature ... (snip) ... organisation ... benefits. One of the tidbits in the flight instructors handbook are the so-called Principles of Learning, which
        Message 3 of 5 , Aug 3, 2007
        • 0 Attachment
          --- In scrumdevelopment@yahoogroups.com, "Adrian Mowat" <mowat27@...>
          wrote:
          > In summary, if has been found that animals "imprint on the first creature
          > they see shortly after birth" and the author of the post argues that
          > developers have a similar reaction to trying new tools.  

              (snip)

          > I believe we often see a similar effect when trying to get an organisation
          > to try new Agile ideas - no matter how hard we work to explain the benefits.

          One of the tidbits in the flight instructors' handbook are the so-called "Principles of Learning," which we are expected to take into account as we help students change their behavior from that of non-pilots into those of pilots.  

          The one that you note here is that of primacy -- what is learned first persists more strongly than that learned later -- and is the principle behind the effects of
          • unproductive habits of thought often needing to be "unlearned" before productive habits can be introduced, and 
          • new concepts which conflict with old knowledge facing strong mental opposition from some students (e.g. "being up in a small plane doesn't mean you are going to die" or "working without a lot of analysis up front doesn't mean your project is going to fail")
          Sure, the concept of primacy makes sense to us, and is something we should all take in mind when, as ScrumMasters, we also act as flight instructors to organizations who seem to be barely crawling. :)

          But your post got me thinking: when I learned about the principles of learning, I learned that no particular one trumps any other.  Thus, sometimes a student who is blocked due to an early "improper" learning can be helped through their block by countering it with knowledge reinforced by one of the other principles.

          So perhaps some of the other principles of learning can help here too, as we try to get our organizational "students" to change their "learned-first" behavior from those of non-agilists into that of agilists. For the record, they are:
          • PRIMACY -- discussed above.
          • RECENCY -- things most recently learned are best remembered. Also, the farther someone is removed in time from a new understanding, the more difficult it is to remember and understand. 
          • EFFECT -- learning is strengthened when accompanied by a pleasant / satisfying feeling, and weakened when associated with an unpleasant feeling.  Don't make people feel inferior if you are trying to get them to understand Agile.
          • INTENSITY -- a vivid / dramatic / exciting experience teaches more than a routine or boring experience.  People learn best from the real thing, rather than from a presentation or book.
          • EXERCISE -- Things most often repeated are best remembered.  Said another way, "practice doesn't make perfect, practice makes permanent."
          • READINESS -- people learn best when they are ready to learn, and don't learn well if they see no reason for learning.  Often heard in high schools as "is this going to be on the test?" :) This one is the hardest for instructors to affect.
          I was going to start listing some ways to apply these toward guiding others in Scrum but it's probably pretty obvious and this post is getting long enough. :)
        Your message has been successfully submitted and would be delivered to recipients shortly.