The Coad Letter: Modeling and Design Edition, Issue 80, Accelerated Analysis, by Stephen Palmer
Welcome to issue number 80 of the Coad Letter.
The first process of Feature Driven Development builds an initial, overall
domain object model for a project. Modeling in color is the best technique
I know of for doing this. A set of workshop style sessions is the best
process I know of for doing this.
We've looked at the modeling in color technique a number of times
over the last 12 months. This month I would like to share with you why
I believe the workshop sessions are such an effective way of accelerating
a team through initial analysis of a problem domain ... and provide some
hints on making these sessions more effective.
By the time you read this I'll be on my way to JavaOne. TogetherSoft
is a Gold Sponsor this year so, for those going, please do stop by the
exhibition booth and say hi.
ps This month marks my first anniversary as editor of the Coad Letter
so I'd like to say thanks for reading and for all the kind feedback that
you have sent.
The overview section of Process
#1 of FDD, as written in the Java Modeling in Color book, says:
Domain and development members, under the guidance of an
experienced component/object modeler (Chief Architect) work together in
this process. Domain members present an initial high-level, highlights-only
walkthrough of the scope of the system and its context. The domain and
development members produce a skeletal model, the very beginnings of that
which is to follow. Then the domain members present more detailed walkthroughs.
Each time, the domain and development members work in small sub-teams (with
guidance from the Chief Architect); present sub-team results; merge the
results into a common model (again with guidance from the Chief Architect),
adjusting model shape along the way.
The rest of the process description goes on to describe the tasks performed
in a little more detail. The process description is designed to be concise
and well bounded (not too specific and not overly generic). Quite rightly
the process description does not include why the process defines the tasks
and responsibilities that it does. Neither does it supply many hints or
tips on performing the process.
Why build a domain object model
A domain object model is like the road map that guides the journey; without
it your team can very quickly end up driving around in circles, continually
reworking and refactoring the same pieces of code. In this process, the
map makers (developers) explore the land (the problem domain) with people
who live in it (the domain experts) and together they produce that road
map to follow for the rest of the project.
To use a different metaphor, if the technical architecture is the foundation
of the building, the object model is the steel and concrete framework within
which you build everything else. You might not need one when building a
garden shed, or even a basic house, but for a skyscraper, success will
be limited and very temporary without one. The overall object model helps
maintain the conceptual integrity of the software system just as the steel
and concrete help maintain the structural integrity of the skyscraper.
Using it to guide them, developers produce better designs earlier. This
reduces the amount of times a team has to refactor their classes to add
a new feature.
Benefits of building an object model as a team
Often one or two elite analysts develop an object model and pass it as
a large volume of documentation to a team of programmers to implement.
FDD process #1 recommends a more accelerated workshop style approach. This
approach involves people from both sides of the business analysis/development
divide, working together as a team to produce the object model. As analysts
and developers learn of requirements, they start forming mental pictures
of the desired system. Unless they are very careful they make assumptions
about this imaginary system. These unspoken assumptions can cause inconsistencies
between different peoples work, ambiguities in requirements documents
(yes, even in use cases), misunderstandings, miscommunication, and the
omission of important details. Developing an overall domain object model
as a team forces those assumptions out into the open, misunderstandings
are resolved, holes in understanding are filled and a much more complete,
common understanding of the problem domain is formed.
Splitting into teams of two or three and working concurrently on the
same area of the problem domain, engages everybody in the room. Multiple
small teams attack the problem from slightly different angles and pursue
different lines of thought. When the results are compared, there are multiple
solutions to choose from, all with their own strengths and weaknesses.
Multiple minds, fully engaged and different solutions explored and considered
concurrently - good fun and great results.
The resulting model is a team effort and you immediately have buy-in
from the developers because they helped build it. No more meetings with
analysts justifying and defending their object model as developers try
to get to grips with it.
Communication between the business and development, between users and
analysts, and between analysts and developers is often poor in a software
project. It is frequently blamed for many projects delivering results that
do not match the client's expectations. Working together in small groups,
and as a whole team in the same room, helps the modeling team members learn
to communicate with each other; a skill that can be used throughout the
rest of the project.
"Once a team begins to jell, the probability of success goes up dramatically"
DeMarco & Lister, Peopleware: Productive Projects
and Teams, Dorset House
The result of the modeling workshop is not just a great object model
but a jelled team ready to take on the rest of the development. The energy
and enthusiasm generated by the creative activities raises the morale of
the team. There is a real sense of achievement as a team when significant
object modeling results are achieved. The first one of these I participated
in, still ranks as one of the highlights of my career.
At TogetherSoft we have seen this workshop approach work so well, time
and time again. Our How To Build Better Object Models (HTBBOM) workshop
is designed specifically to enable our clients to experience this while
learning better object modeling techniques and strategies. A TogetherSoft
mentor takes the role of Chief Architect and takes a team through process
#1 three times; twice on simple problem domains and then through part of
the client's own domain. Not only does the team learn through listening
and doing together, they get the chance to apply the principles
to their own problems with guidance from an experienced object modeling
mentor. TogetherSoft does offer the same material in a shortened
format as public training workshops. However, these do not provide the
team building experience or generate real results in anyway as effectively,
as a workshop with a real project team; the attendees mainly come away
with a set of new strategies and patterns to try on their own work. Anyway,
that's the end of the blatant advert and onto some tips :-)
Hints and Tips
1. Forming the team
A skilled facilitator is required during the object modeling. A skilled
chief architect is also required to ensure the resulting object model is
the best possible. A person that can play both of these roles is a great
but rare commodity. If required, pair the chief architect with someone
with good facilitation skills to lead the workshop as a team.
An ideal team size is between six and twelve people in addition to the
chief architect/facilitator. This allows the team to split into multiple
smaller teams of two or preferably three. Any more than twelve becomes
hard to facilitate and we are into diminishing returns for each additional
person participating. Any less than six and the splitting into smaller
groups gets rapidly less effective.
For larger teams, keep a core team and rotate the other development
team staff through in ones or twos so that they get a feel for the process,
the domain and the object modeling techniques. If the room is big enough
others can also sit in and observe (no participation allowed).
The core members of the team should include the lead developers, domain
experts and some of the better analytical developers. A mix of two thirds
developers and one third domain experts seems to work well because, when
working in threes, each pair of developers has a domain expert to provide
domain guidance. Domain experts can be users, clients, sponsors, business
analysts or any mix of these. We need them to be good team players, enthusiastic
about the promise of the new system and above all, patient as developers
ask basic questions about their business.
Mix the small group membership up every now and again to ensure everyone
works with everyone else and to change the dynamics if progress is becoming
stodgy. Do not encourage small groups of more than three; the fourth either
becomes a 'manager' of the group or has to strain to hear and see what
the others are doing.
2. Setting the Rules
The first time a team attempts to work in this workshop style, take fifteen to
twenty minutes after initial introductions to explain the Lessons Learned from
Fred (see CoadLetter
#40) and as a team agree on the norms to use during the modeling sessions.
3. Setting the Environment
I have tried a number of different environments and found a conference
room style setup to work best. The room needs to be big enough for the
modeling team to sit comfortably around a central table. A good mix of
windows and wall space gives plenty of natural light and space to hang
the results of the work as it progresses. It's hard to feel creative in
a classroom atmosphere especially if that classroom feels like a cave because
it has no windows.
Recommended materials include:
Flip chart pads and stands. Ideally we want one stand for every three people
in the modeling team though this is not critical. The modeling team will
demolish two or three standard size flip chart pads in a week.
Post-It notes. Here we want the standard 3 inch square size. The modeling
in color technique uses the usual four pastel shades of pink, yellow,
green and blue. Other colors are distraction, do not use them.
Permanent Marker pens. These should not be too thick; the Banford Sharpee
Fine Point Permanent Marker are the best I have used to date. Beware marker
pens that bleed through paper (like some whiteboard markers); their contribution
to the décor may not be universally well received.
Pencils and Erasers are useful for thinking aloud until a group is ready
to ink in names and associations.
Masking Tape is needed for hanging flip chart sheets on the wall. The Post-It
note style flip chart pads that stick to the wall on their own reduce the
need for the tape. However, it is still needed if you want to hang the
sheets in landscape orientation.
Correcting tape to 'white out' those 'inked in' names and associations
that were not quite right.
A whistle for the facilitator to use to get the attention of the team when
working in small groups. Yes - the small groups can get so immersed that
it is hard to pull them out of it.
A soft ball to use a token during intense team discussion; only the person
with the ball may speak.
A CD player to provide background music during small group work. This is
especially useful for playing some lively music in sessions just after
4. Setting the Scope
For a team new to this process, a very useful and simple warm up activity
is to break into groups of three and prepare a statement of purpose for
the project. Set a time limit of 10 minutes and a word limit of 25 words
or less. Keep the statement high level and avoid technology terms like
scalable (sounds like a characteristic of a fish or a rock face);
the purpose should communicate to the domain experts.
Get each small group to read out their result. As a team, compare and
contrast the results, highlight good words and phrases in each, and then
volunteer two or three people to merge the small group statements into
one statement while the others are on the next coffee/tea break.
In doing this, the team gets some initial practice at splitting into
and working in small groups, presenting results and comparing them. The
facilitator sees the group in action for the first time and can note the
initial group dynamics and personalities in the team. The result provides
a focus for the team and the project. The team may tweak the statement
occasionally as requirements become clearer but the team can now answer,
in a couple of sentences, the question, What does this system do?.
Have fun building better object models!
©2001 Giraffe Productions