Working Together

We will wrap up this chapter by discussing teamwork guidelines for projects on the UML and object-oriented journey.

Modeling Teams

The old saying “too many cooks spoil the broth” is true for modeling. When you assemble teams to model your system, subsystem, or application (whatever level of abstraction you are working at), large teams can be disastrous.

Our experience shows that on a team with more than five people, progress will not be forthcoming. Because you can model a system in so many different ways, a large group of people might never agree on the representation of the systems.

On the other end of the spectrum, a modeling team needs to have a certain critical mass. At least one person on the team has to have business or domain expertise in the area in which you are working. For example, if you are building a system to support commodities trading, you need someone who is an expert in commodities trading. Also, at least two people on the team should have expertise in UML modeling. Why two? As we mentioned, you often can model a business or system in many ways. By having two expert modelers on your team, you can ensure balance. We have seen some modelers become so enamored with a particular modeling technique or pattern that they try to apply it to every problem they encounter. With a second modeler, you add another perspective, and the team will be more likely to come up with a better design. Plus, the team members can learn from each other's experiences, and both become better at their craft. In summary, a modeling team size of three to five is very effective.

As you begin working with your team, you might notice that the business expert will begin to understand some of the modeling concepts. As a result, he mistakenly might begin to assume he fully understands UML modeling and object-oriented techniques. Make sure you make it clear to everyone on the team that the modelers are responsible for modeling and the domain expert is responsible for explaining the “business” concepts that the modelers will depict.

The War Room

When multiple teams are working on the same project, it is very useful to create a “war room.” This is a common area where all the teams post their models on the walls so that every team can see the state of every other team's designs at any time. A war room also provides a common meeting area where a team can work, surrounded by all of their models.

Togetherness is a wonderful thing. Although we recommend you create a war room for your project teams, you need to make sure the teams don't live in the war room and do all their modeling work together, all the time. We have seen such consensus modeling attempted; it is not effective for long and will cause the team to burn out quickly. Team members also need some time to themselves to work on their individual designs, to consider what they have learned from other team members, and to synthesize new ideas and concepts. Because modeling is a creative activity, your people will need some “quiet time” to be creative and then collaborative time with the other team members (in the war room) to exchange and review their designs.

Also, regarding collaboration, when you do establish a group of mentors in your organization, you should utilize them to review your designs periodically. This is particularly valuable when you are approaching an important design review. Your project benefits from their experience, and they benefit by gaining new knowledge about yet another project that they can use as they mentor others.