You are currently viewing The Scatter-Gather Mode And How It Works

The Scatter-Gather Mode And How It Works

  • Post published:April 9, 2015

The number one issue with developers today (especially freelancers) is that they are so thinly spread that they’re often unable to manage the multiple projects they hack onto their agendas at a time.

At vteams we tackle things slightly differently. Each of our individual teams is dedicated to one project at a time, effectively providing the client a virtual team that is at their disposal for the duration of their time with us. As each project is different, each team’s structure, organization and methodology is different.

Enter our scatter-gather method; each task is divided into multiple smaller-scale tasks. One recent example in which this method was used can be found in a client’s business site. It had grown and therefore had feature lists and enhancements that needed daily maintenance at an urgent level.

Scatter-gather was especially effective in this case as each member of the particular team assigned was entirely dedicated to one specific feature. No one was spread thin, everyone had a distinct and consistent duty to maintain and by the end of the project’s development, each team member’s code was integrated in order to produce that feature.

But what if somebody’s sick?

There are occasional issues with each team methodology. Especially relevant to the scatter-gather method is when one team member is absent for one reason or another. As it takes each member of the team to successfully integrate code, failure to prepare for such absences could mean a full-on cease to the flow of the project.

In order to avoid this, we introduced a document writer, who would gather domain knowledge and document all of our major modules at a rapid enough pace for us to keep real-time track of updates and alteration in code. The document writer is sure to detail even more abstract aspects, such as why a certain feature is developed the way it’s developed, why a certain flow is designed differently, where a particular team member leaves off and the core integration read that need to be tested and maintained after any modification is completed.