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

RE: [scrumdevelopment] mention of Scrum in "Software Development"

Expand Messages
  • Mike Beedle
    ... Paul: Yes I prefer descriptive, and I think you capture that well with the concept of reasonable options . However, I would prefer not to use the word
    Message 1 of 40 , Nov 12, 2003
      Mike wrote:
      >
      > As in programming a "prescriptive" process means step-by-step e.g. C,

      > Java or C++, while "descriptive" means declarative: i.e. rule-oriented

      > or functional.

      Paul wrote:
      > So you'd prefer descriptive as an alternative to prescriptive, where
      > 'descriptive' would be a subset of ad-hoc - and potentially the only
      > reasonable options from the 'ad-hoc' bag. Are we making a fuss over
      > nothing here?

      Paul:

      Yes I prefer descriptive, and I think you capture that well with the
      concept of "reasonable options". However, I would prefer not to use
      the word "ad-hoc" because in our industry "ad-hoc" is often
      interpreted as:

      "anything goes", "cowboy coding", "trust your guts",
      "only-the-expert-knows", "on-the-fly", "pulled out of a hat",
      etc.

      So I prefer to say that agile development is "constrained by
      rules and molded by practices".


      > I prefer more:
      > more human interactions, like mentoring, over process and tools
      > (Wait I think I heard this somewhere else:
      > http://www.agilemanifesto.org
      > )

      Paul wrote:
      > Right. Mentoring isn't the only way of transferring knowledge, but I
      > agree it's a good way of doing it if the mentors are available, if the

      > need for mentoring is recognised, if the mentors are giving the right
      > advice.

      Mentoring is not the only way to learn but it is the best way I know
      of transferring knowledge, software development or otherwise.

      "Example is not another way to teach ... it is the only way."

      Paraphrasing A. Einstein

      Paul describes:
      >There was a description, I'm afraid I don't know the origin, of the
      >progress in learning how to do the job of software development. One
      >progresses from Unconscious Ignorance through Conscious Ignorance to
      >Conscious Competence and eventually to Conscious Competence.

      Makes sense:

      | Unconscious Ignorance
      v
      | Conscious Ignorance
      v
      | Unconscious Competence
      v
      | Conscious Competence
      v

      Nonaka and Takeuchi talk about "tacit" and "externalized" knowledge,
      btw.

      Paul writes:
      >What I'm looking at is a vast reservoir of Ignorance, usually
      >Conscious, and a limited set of agile methodologies that seem to be
      >aimed at the Unconscious Competent.

      Imo, agile practices work well even when a mixture of expertise is
      present
      in the team.

      But, imo, no method or process can compensate for the lack of
      technical expertise. That's not something that any process can cure.


      Paul writes:
      > If 'agile' is ever to become mainstream, there aren't enough mentors
      > to go round, IMHO. I think if we can get people started in thinking
      > about process, then the mentors will have had the donkey work done for

      > them.

      It depends on what you understand by process.

      I would agree that learning more techniques is good:

      * learn *everything* about your development language
      * learn how to write good tests
      * learn how to capture stories or use cases (I'd recommend the
      stories)
      * learn object modeling
      * learn most about you development tools: config. manag.
      testing, IDE's, editor,
      * learn *all* about the database flavors you need to work with
      * learn more about your environment: app servers, Oss,
      communications
      * learn more about networking, security
      etc.

      But I would not say this is "process". Process to me is
      about how are roles defined and how they interact with each other:

      - the "Business Analyst"
      - the Business Process Analyst"
      - the "Architect"
      - the "Use Case Analyst"
      - the "The Tester"
      - etc.

      That knowledge, in an agile world is not very useful, imo,

      - Mike
    • Jeff Sutherland
      While I agree with Mike in general, it is of interest that the first Scrum was building an OOAD tool and we decided the team should eat their own dogfood. It
      Message 40 of 40 , Nov 14, 2003
        While I agree with Mike in general, it is of interest that the first Scrum
        was building an OOAD tool and we decided the team should eat their own
        dogfood. It was also the first round trip engineering tool.

        Every developer had the model of his components on his wall.

        Our senior consultant, Jeff McKenna, an ace Smalltalker, would walk into a
        cube and an hour later the model was in shreds on the floor. He had shown
        the developer how to refactor the model and eliminate half the code while
        enhancing performance and functionality.

        I've never seen another team that can operate at that level.

        Jeff

        At 05:07 AM 11/14/2003, Mike Beedle wrote:
        >...
        >
        >Mark wrote:
        > > Mike has said repeatedly that he feels that
        > > modeling isn't necessary in order to produce quality code. Scott
        > > Ambler, myself, and some within the XP community have the opinion that
        >
        > > modeling, when necessary, and to the proper level of detail and
        > > formality, provides an important element in the design and
        > > implementation of software.
        >
        >This is also a fact:
        >
        > We produce hyper-productive, high-octane, high-quality,
        > high-quantity software with little or no models.
        >
        >So no, models are not important to us, as they are not as
        >important to most agile developers. (We minimize "documentation time"
        >by documenting after the fact.)
        >
        >But like I said earlier, if you feel modeling helps your team, or
        >is needed for political reasons, or you like how the models look on
        >display on the walls, hey, more power to you.
        >
        >Good luck with all of your projects!!!!
        >
        >
        >- Mike
        >
        >(It was nice to talk to you on the phone earlier this evening, btw.)
        >
        >
        >Mark wrote:
        > > P.S. I'm looking forward to taking the CSM course some time in the
        > > near future. Perhaps I'll walk away cured of my modeling sickness. :-)
        >
        >In 1994-1996 I was involved in a 100+ person, 30 million dollar
        >software development project. By year 2 we had 1000+ pages of:
        >
        > Elaborated Use Cases
        > Class Package Diagrams
        > Class Diagrams
        > Sequence Diagrams
        > Test Plans
        >
        >but no working software. Within the last 4 months of the project
        >I took over the project, *ignored all the previous models*,
        >applied Scrum to the project and delivered the first instance
        >of the application to production on 1/1/1996.
        >
        >(I have many other, almost countless experiences like that.)
        >
        >This is why I don't do models anymore -- they NEVER delivered the
        >goods for me in the trenches.
      Your message has been successfully submitted and would be delivered to recipients shortly.