Increase your team's velocity by doing things that make sense

Let’s imagine the life of the average developer in a larger organization. Requirements (or even user stories) appear via some semi-opaque process, progress is driven towards seemingly arbitrary deadlines that are nevertheless treated with grave importance, and once completed, features are released to some faceless group of users where they receive some sort of unknown reception. Then the process repeats.

Occasionally this flow will be disrupted by urgent feature requests that arrive out of nowhere and take priority over everything else. Sometimes the features being requested will be mystifying – seeming impossible to be of use to anyone who actually uses the system. This, however, won’t affect the urgency applied to get them completed.

Sounds fulfilling, right?

A few things to note. First, though I’m painting an exaggeratedly bleak picture, if you look honestly there are potentially elements of this narrative present in your organization. Second, we should all recognize how lucky we are to even contemplate being fulfilled by our jobs above and beyond being able to eat and have shelter. Motivation and fulfillment are serious things, but let’s keep our sense of perspective intact.

If your teams don’t understand why they are working on something, who it is for, or how it will help them, how can you expect them to be efficient, much less committed? Software is made by people, remember? Knowing who they are building for helps teams stay motivated. Understanding how the requested functionality will make users’ lives easier helps teams feel fulfilled.

Beyond that, when teams understand why they are being asked to deliver certain things on certain timelines, they are better equipped to ask intelligent, challenging questions and provide more relevant feedback. The daily process of making software involves a nearly continuous stream of decisions, many too finely-grained to bother documenting or discussing. Without appropriate context, individual developers could choose sub optimally, or worse, miss the looming signals of a poor-fitting or irrelevant feature. Make sure your teams know why they are being asked to build something and what it is supposed to accomplish and they’ll tell you when something doesn’t make sense.

How do you make sure this happens? One big assumption here is that you are, in fact, trying to do something that makes sense. Keeping your team informed about the overall strategic purpose of your efforts and the people you are aiming to benefit presupposes that you have a purpose and a deep knowledge of your users. If you can’t succinctly explain your strategy and your target users to your team, you aren’t done on those fronts yet.

Set a challenge for yourself to make your teams informed partners in the overall vision and use that as motivation to arrive at a concrete strategy, informed by an objective understanding of who you’re actually making this stuff for.

I cover more on this and other topics in my webinar with Forrester here.