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
Robert Henley, I believe, commented that this "deadly
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
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
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
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.