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.

Have fun

Steve

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.

Accelerated Analysis

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.

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.

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

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!

Comments?
 

©2001 Giraffe Productions