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

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

Expand Messages
  • PaulOldfield1@compuserve.com
    (responding to Mike B) I think I need to say a few words in defence of Scott here, because I m trying to address the same problems and, as someone just
    Message 1 of 40 , Nov 12, 2003
    • 0 Attachment
      (responding to Mike B)

      I think I need to say a few words in defence of Scott here,
      because I'm trying to address the same problems and,
      as someone just learning about Scrum, have the same
      perceptions of it as he seems to show. Maybe you can help
      us both by pointing out where we're going wrong.

      > 1) Agile is descriptive not prescriptive
      >
      > You have to remember that Scott Ambler is the guy that
      > wrote, not one, but TWO patterns books where all patterns
      > came out from a CMM decomposition of software
      > development processes.
      >
      > Might I add that PRESCRIPTIVE process and/or
      > organizational patterns are mutually exclusive with
      > agility by definition?

      I don't think all organizational patterns are mutually exclusive
      with agility. Where such a pattern is right for the situation,
      surely an agile approach would allow, maybe even recommend,
      its use. To select a pattern and say it should always be used
      is wrong, as in not agile. To give advice on the situations in
      which it would be pertinent is enabling a degree of agility,
      I'd say it was agile. Of course, ideally, we would not
      *need* to give such advice, because the team would just do
      it when it became the right thing to do.

      I think this is an important issue, because I'm trying to look
      at what makes a process appropriate, in order that I can
      lead people toward more agile processes.

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

      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.

      > I would categorize both Scrum and XP as Descriptive
      > software development methods:
      >
      > They depend on the enforcement of simple rules that
      > generate emergent processes.
      > That's what we mean by self-organization in Scrum.
      >
      > He missed completely, as many other do, this _important_
      > attribute of Scrum and XP for that matter.
      >
      > 2) On completeness
      >
      > Scrum can be seen as both:
      >
      > a) a general project management framework (what Ken
      > and I wrote about), and
      > b) as a complete software development methods (what
      > Jeff, Ken, myself and others have been practicing for the
      > last almost 10 years.
      >
      > He missed the point in that Scrum as a software development
      > methods is complete and has been complete for the last 8
      > years. He is only looking at the project management
      > framework.

      I guess I must suffer from the same misconception as Scott,
      I still perceive Scrum in terms of what Ken and you wrote
      about. I think it's a fair point of view to hold, because that's
      where anyone new to Scrum will be starting.

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

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

      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.


      Paul Oldfield

      ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
      www.aptprocess.com

      any opinions expressed herein are not necessarily those of
      Mentors of Cally or the Appropriate Process Movement
      ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
    • 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
      • 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.

        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.