In one of my first consulting engagements over 15 years ago, a customer said to me a something that sticks with me through to today regarding working in a group.

“Nobody knows my mind like I do, and even I don’t always know it.” (anon)

What he joked about are the issues that arise when working as part of a group.

Benefits of team-based development

Before we address the challenges of team-based development let us talk about the benefits.  Broadly speaking there are 3 primary types of benefits.

1. Faster development time: By distributing the work over multiple people the project can be completed more quickly.
2. Multiple areas of expertise: Additional people can bring domain-specific knowledge to a project.
3. Error reduction: Having multiple people work on a project can reduce the chance of “developer blindness” where you do not see your own mistakes.
4. Chance for “team” lunches: When you work as part of a group you can have group celebrations.  When you work by yourself it is just lunch.

What are the challenges?

There are three primary types of challenges for team-based development.  They are

1. Communication:  Both ensuring that all information required is communicated and that it is clearly expressed.
2. Blocking: When more than one person requires direct access to a set of files to for their work or their work is dependent on another person.
3. Standards: Every developer has different ways of solving problems; in some instances, these approaches will be in conflict.

 

 

Mitigating these the challenges

As the title of this section states, these challenges can be mitigated, but never fully eliminated.  The following recommendations will help reduce these challenges.

Challenge 1: Communication

Good communication starts with a commitment to good communication; the team needs to recognize the need for some form of formal transfer of knowledge.  Often this takes the form of a Requirement Document.  However, it is not enough just to have a requirement document; it needs to be used.  Use of a requirement document implies the following

1. Referenced: The requirement document is referenced during the creation of artifacts
2. Tested: Test cases are derived from the requirements documented
3. Traced: The use of the requirements is validated throughout the development cycle
4. Living: The document is updated as changes are required.

Failure to follow these steps will lead to communication breakdown.

Challenge 2: Blocking

Blocking is addressed through architectural constructs and version control methodologies.  Models can be architected to allow each person to work on individual components while still facilitating integration into a large system level model.  In the instances where two people need to work on the same model, and it cannot be subdivided, then version control software can be used to create a branch for each person to work on and then merge their changes once they have completed there work.

It is of the highest importance to validate the models’ behavior after the merge to ensure that the functionality added by each person still works in the merged model and that the baseline functionality has not changed.

Challenge 3: Standards

While standards may be complete or incomplete, there is no “right” standard.  The key is complying with those standards.

A “complete” standard is often a series of standards addressing

1. Each stage in the development:
   1. How to write requirements
   2. How to write tests
   3. …
2. The handoff between stages:
   1. What artifacts are created when you start developing a model
   2. What artifacts are created when you run a test
   3. …

 

Final thoughts

In this post, I have not specifically addressed Model-Based Design.  The recommendations for mitigation can be directly linked to earlier posts I have made on topics such as modeling standards, version control, and model architecture.  Finally, with models acting as the “single source of truth” during the development cycle many of the handoffs and blocking issues of team-based development can be avoided.