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

Boston AgileBazaar Meeting Minutes

Expand Messages
  • Ken Schwaber
    I m posting these notes because I think the discussion at the meeting is generally of interest. The Boston AgileBazaar held it s third meeting at Chuck
    Message 1 of 1 , Sep 20, 2002
      I'm posting these notes because I think the discussion at the meeting
      is generally of interest.

      The Boston AgileBazaar held it's third meeting at Chuck
      office in Brookline Village on Thursday, September 19. Ten people
      attended the meeting.

      I'm responsible to the AgileAlliance for helping user groups get
      started, and the meeting was very instructive since my knowledge of
      user group startup is essentially nil. In the previous meeting we had
      proposed that meetings start with someone presenting a problem, and
      then the group discussing how agile processes would address it.

      We started the meeting by bemoaning the state of the software
      industry, where more and more hype and marketing is connected to less
      and less product. Tom Stambaugh used the example of MacroMedia's
      development products, which are a product suite that is "fully
      integrated." It turns out that integration is no better than DDE
      10 years ago, not even OLE automation!! Jeff Sutherland, Mike Smith
      and myself indicated that we have quite a bit of success with
      DreamWeaver 4.0, a five year old release that has more functionality
      and less hype.

      This led to a discussion about how we would go about quickly building
      a content rich website. Everyone had a different approach, ranging
      from .NET and VisualStudio to Blogger to ZOPE. As we were discussing
      the merits of each approach, it reminded me of a lot of projects that
      I've seen get bogged down over the wealth of technical
      and the different preferences within the organization. We've used
      Scrum to break through this "deadly embrace" by starting a
      essentially time-boxing the team into delivering some functionality
      on a single selected technology. This forces the issue. Several
      people expressed concern that this could lead to incorrect long term
      technology selections.

      Robert Henley, I believe, commented that this "deadly
      embrace" was
      a "organizational bad smell," similar to the bad smells that
      from an engineering viewpoint during XP projects. He wondered what
      other organizational bad smells might be, suggesting that Jim
      Coplien's antipatterns might be a start. Another source might be
      listed in Software For Your Head, Jim and Michele McCarthy, where
      core protocols are listed.

      Robert and Chuck discussed that software structure mimics
      organizational structure, quoting Conways's Law from a letter to
      editor of DataMation (who remembers that?) in 1968, to paraphrase
      as "team=product." This led us into more discussion about the
      resistance of organizations to agile processes and the reliance on
      and fallback to command and control processes. Chuck has had some
      success implementing change of the agile, team-based type, but he has
      really worked at it and it's his expertise. Nancy
      pointed out that of all of the articles in a recent issue of Cutter
      IT Journal ("XP and Culture Change", September 2002), almost
      all of
      the articles presented failures of agile implementations. We then had
      a generally freewheeling and very lively discussion about
      organizational dynamics, introducing team-based development into
      traditional command-and-control organizations, analogies between
      software and organizations (Tom – "what is the organizational
      equivalent of a unit test, and what does an organization look like
      that doesn't have one?"), and how success can be wrestled
      from the
      jaws of this problem.

      Steven McDonald discussed his attempts to use agile processes within
      his organization, which is a CMM level 2 organization. To date they
      have frowned on his efforts. I mentioned that, for better or worse,
      I'm building a version of Scrum as a methodology that is mapped
      CMM level 2 for the use of one of my customers. I felt that
      success in traditional command-and-control organizations was because
      Scrum established a very defined, rule based set of practices that a
      command-and-control manager would feel as familiar, while allowing
      agile and team based practices to flourish and be protected within
      the rules. Hopefully, the CMM related version will extend this
      direction of comfort and compatibility.

      As we approached 8pm, Tom brought up that we still hadn't decided
      we were and what we would do, even though we seemed to like it so
      far. The fear is that without some more structure and guidelines we
      might start floundering. For instance, should we have more than a
      wiki. Should we have a website and a email address capability?

      The next meeting was scheduled for October 17 (another Thursday!) at
      Chuck's office. We will work to establish a product backlog or
      set of
      stories about topics that we will discuss prior to then and use them
      as starting discussion points for that and possibly further meetings.
      The wiki will be used to develop this list.
    Your message has been successfully submitted and would be delivered to recipients shortly.