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

Discussion of purpose of Light Weight Methodologies

Expand Messages
  • Ken Schwaber
    Some pretty interesting discussions are occurring re. the role of lightweight methodologies (Scrum has been grouped herein), particularly as considered to that
    Message 1 of 1 , Jan 7, 2001
      Some pretty interesting discussions are occurring re. the role of
      lightweight methodologies (Scrum has been grouped herein),
      particularly as considered to that of traditional methodologies.
      Below is an excerpt.
      Ken S.

      I think another issue we might discuss is whether or not we want some
      form of joint effort, knowledge sharing, definition of
      core "principles" or "practices" of light methods, etc. to follow on
      from this get together. I realize the answer to this question will
      depend on what happens when we get together, but it might be a later
      agenda item. For example, I could see going forward using a modified
      OpenSource? type model.

      This is also an issue of whether or not we want to "promote" Light
      methods as a group. Many of us are already doing this in an informal
      way, siting each other's work in articles, books, and talks. Do we
      want to promote in other ways?

      There seems to be tremendous momentum for LMs lurking. More than
      lurking at the development level, but still just breaking through at
      the executive/management level. Do we want to capatilize on it? How?

      --Jim H.

      And, if simple methods are to make the breakthrough, is there an
      issue of branding? If you follow the core principles, should you able
      to get some kind of LIMBO stamp of approval
      (LowInertiaMethodsBrandingOrganization?). I can see some pluses, and
      probably even more minuses, but I'd like to discuss the concept. --

      Under "definition", or applicability, I think LWM (certainly Scrum
      and other adaptive approaches) is most beneficial and maybe only
      applicable to complex development situations. I saw a very good
      description of this "complex" situation on

      Interesting article. Also interesting to me that you and JimH? keep
      talking about LWM being "mostly" applicable to complex, rapidly
      changing environments... in fact, I'm starting to have to fend off
      discussions that start with that assertion. I have only ever worked
      in LWM ways, and some of those were fairly high certainty situations
      (I don't think there is really ever a high certainty situation in sw
      devt, or any to spend time worrying about). So I'd like to rehash
      this a little, just to see if we can negotiate our way around
      this "complex situations" heuristic. --AlistairCockburn

      Alistair, one reason I focus on "complex" situations is that it gives
      me a wedge to get in the door. People at least have some idea that
      they need help on these type projects. Essentially I want them to
      come to their own conclusion that the practices have wider
      applicability rather than my telling them. -- JimHighsmith

      Right... not everyone understands that the inverse and converse of a
      proposition are not equally true. I agree with the "if we have a
      complex, rapidly changing situation, we'll need a light, adaptive
      process." But I just finished trying (unsuccessfull, no doubt) to
      assuage a person who wrote in, "we don't have a complex, rapidly-
      changing situation, so we probably can't justify using a lightweight
      method." Argh! I get similar lack of logically sound derivation on
      the topic of XP. So maybe there is a way to construct the message
      that doesn't lead people to the trouble of parsing an IF-THEN
      statement. (I just bought the book "Don't Make Me Think!", and find
      it so apt.) Ergo, I'd like to consider discussing this topic in Feb. -

      LWM's require experienced, technical management to make correct
      decisions quickly. Also, they work a lot better with experienced
      engineers who know the techniques, tools, and software engineering.
      Then the whole group can meaningfully survive building new products
      with new tools and technologies. However, these "experienced" people
      cost more and want more interesting work, so they are usually only
      found on complex projects.
      I haven't worked on any "simple" projects lately, but my
      characterization of them is that they must be IT projects, probably
      have relatively inexpert staff and management, and can use the most
      detailed instructions possible ... hence I think of these projects
      and heavy methodologies in the same breath.
      I've only tried Scrum on two products with inexperienced staff and
      they both reminded me of the EDS commercial where some cowboys are
      herding cats to market.
    Your message has been successfully submitted and would be delivered to recipients shortly.