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

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

Expand Messages
  • Mike Beedle
    ... Paul: Sorry, my sentence should be parsed like: PRESCRIPTIVE process and/or organizational patterns i.e. All process and organizational patterns that
    Message 1 of 40 , Nov 12 8:49 AM
    • 0 Attachment
      Mike wrote:
      > Might I add that PRESCRIPTIVE process and/or
      > organizational patterns are mutually exclusive with
      > agility by definition?

      Paul wrote:
      > I don't think all organizational patterns are mutually exclusive
      > with agility.


      Sorry, my sentence should be parsed like:

      "PRESCRIPTIVE process and/or organizational patterns"

      i.e. All "process and organizational patterns" that are


      DO ETVX task1
      DO ETVX taks2
      IF ITVX task2.state == somestate THEN
      DO ETVX task3
      ELSE DO
      DO ETVX task 14

      This is what I was referring to.

      If the above steps are part of the software development process,
      agile is less about that.

      It is more about "if in situation X do Y is a good solution"
      i.e. declarative or rule-oriented.

      Mike wrote:
      > His analysis is flawed because the options prescriptive
      > and adhoc, do not describe the universe of possibilities.

      Paul wrote:
      > I'm not sure what you're trying to say here. Prescriptive, as in
      > selecting a process element to be used in all cases, and ad hoc, as in

      > selecting a process element to be used in a particular case, should
      > cover all possibilities. It may not be the best way to divide the
      > possibilities, it's the way he selected for the purpose at hand.

      As in programming a "prescriptive" process means step-by-step e.g.
      C, Java or C++, while "descriptive" means declarative: i.e.
      or functional.

      Paul wrote:

      > What I perceive, right or wrong, is that Scrum is a management
      > framework, that enables self-organising teams to get on with
      > development unhindered. It doesn't give guidance as to how those
      > teams will get on with their work. XBreed fills in the "hole in the
      > middle".

      I certainly don't see things that way.

      XBreed is mostly about doing work with multiple teams. I really need to

      change the face of it. Frankly, it got attention for
      the wrong reasons, i.e. the mention of Scrum and XP used together,
      which in all honesty wasn't all that important. (Scrum has had
      long-held similar engineering practices that although not as well
      documented work equally as well.)

      The other "concurrent multiple team" practices are much more important,

      Paul asks:
      > What would be the quickest way toward curing this misperception, so
      > that I can point other folk in this corrected direction?

      Well, as mentioned before on this list, not having Scrum engineering
      practices documented in "many places" is a problem. (If you recall
      a conversation among a few us in the last 2 months that involved
      Ron Jeffries, he strongly recommended writing more about them.)

      The only documentation of "full engineering Scrum" is only
      in web sites, and that is fairly vague.

      We need other Scrum books that describe Scrum as a full "software
      development method", not only its management practices.

      The short cut of course is to use XP's engineering practices
      because in the end are very similar.

      Paul asks:
      > In the environments I find myself all too frequently (except in the
      > recent economic downturn), if the developers did not have a process to

      > follow, they would not know what to do, how to do it, or why they
      > should be doing it. If you'll pardon the fine Scots word, you cannot
      > stock a team with numptys and expect them to organise themselves.
      > What we need to deal with is how to move forward from this
      > situation toward something closer to the ideal.

      Well, I understand your position: if you have "newbies" they do need
      help. But is "more process" the answer?

      I prefer more:

      more human interactions, like mentoring, over process and tools

      (Wait I think I heard this somewhere else: http://www.agilemanifesto.org

      Also, the "need to adapt", and hence to "improvise" goes beyond
      or talent.

      When I show up to the office I never know what is the sequence of
      steps that I am about to follow after our Daily Scrum.

      I know what my "goals" for the day are but *any* combination of things
      might be necessary to get them done:

      * Some days we need to talk back to the customer first thing
      * Some days we are testing hard to get bugs out -- even
      early in the Sprint
      * Sometimes a couple of us start improvising designs
      * Sometimes we sit alone or with a pair and program

      We make the process as go -- every day. So what I do know is that we

      "follow the rules and stick to the Scrum and/or XP practices"

      that will get us there.

      Sorry if my first note was hard to parse,

      - 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 6:54 AM
      • 0 Attachment
        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.


        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.