Never

Which of these descriptions best fits your software development team?

(1) The team is highly integrated with the rest of the company and its customers.

(2) The team is shoved off in a corner.

If your circumstances more closely match the first scenario, well done you. By design or by accident, your structure is helping you circumvent a host of software development challenges.

But if your circumstances are closer to the second scenario, you have to make a conscious effort to provide your team with information that the well-integrated team comes by naturally.

Let’s call that “context.”

A well-integrated team interacts with its end user community on a routine basis. The team sees the software products in use. The team hears complaints and wish list items. The very problems meant to be solved by the team’s products are known and understood by the team through direct observation. Inspiration strikes the team regarding ways in which to improve the product not even dreamt of by the rest of the company—and customers.

In the absence of context, the software development team must rely on one or two people who speak for the entire user community. The pressure on those representatives is great—whether they realize it or not. One omitted detail, one miscommunication, one offhand comment taken too seriously or too literally by the team can spell disaster.

This conduit to the software development team may be the product manager, the product owner or something else. Let’s call him or her “The Voice.”

The Voice has to live by four very black and white categories:

• Never
• Not Yet
• Next
• Now

The software development team is looking for guidance about what features and functionality are coming down the pike—and when. This permits the team to make design, architectural and implementation decisions that will support the future. It also keeps the team from over-architecting the application.

Question: Will this browser-based application ever need to be responsive? Will users ever run it from a tablet or phone?

Answer: Never.

Result: The team expends no effort on responsive design, secure in the knowledge that this is a feature that will not be needed.

Question: Will this application ever be translated?

Answer: Not yet.

Result: The team architects the application to support translation. This is a big, fork-in-the-road architectural commitment. It does add development time—both up front and ongoing. But retrofitting the application to support translation can be an even bigger commitment of time. So if the requirement is likely, then the time spent from the outset is worthwhile.

Question: When do we need to release the new reporting module?

Answer: Next.

Result: This is the ideal answer for a software development team. The feature is important and needed in a relatively short timeframe, but there is time to implement a solid, full-featured solution. Because it is scheduled in the near future, requirements should already be well defined—or at least there should be a stakeholder who knows what those requirements really are.

Question: How soon do you need this search functionality?

Answer: Now.

Result: If a feature is needed right away—because it fills an urgent need or because a competitor’s product is going to take market share due to its absence—the software development team may be able to provide a very rudimentary implementation that just fulfills the requirements. Given more time, a more feature rich or robust implementation may make more sense. The urgency factor influences the implementation details.

Although I have painted with broad brush strokes by characterizing two very different types of teams, the truth is that there are plenty of instances in which the software development team must rely on a voice or conduit of information when access to those who drive a requirement just isn’t possible. Thinking in terms of these three answers—Never, Not Yet, Next and Now—can give the team important insight that can save time and money in the long run.