Finish What You Start

Like most dicta, finishing what you start is easy to say but hard to do. And we're aware of the difficulty both in our personal lives as well as in business. The reason is, like a dictum, it's always easier to talk about something in general than in laborious detail, and it's always easier to talk about details than to physically take the time to do them.

Software development epitomizes this difficulty, and much of the challenge with software in particular is its lack of physical presence. We grow up in a physical world, and we develop intuitions about it. No one thinks that they can get a couple of friends and build a new house over the next few weeks, but everyday in some enterprise, someone from management, or product, or development itself declares in a meeting that they pull together a "two-pizza team" and knock out some enterprise-wide software in a couple of sprints.

Here's an insider observation: they never finish.

This was the initial motivation for Agile, before it became a consulting, billable-hours juggernaut. Do something simple, make sure it's concrete by demonstrating the functionality, or even better, get someone to use it.  Then do the next thing.

But, no matter what, finish something first.

Create opportunities to finish. First, think small. The end goal may be large, but keep the next step as small as possible. Then, when it's done, you know you have one step finished. The more you practice finishing things, the better you get at it.

Next keep your features precise and compact. Vague features are doomed to scope creep, they become very difficult to finish. Large features are also problematic. You may think that you've been precise in defining the 30 tickets for a given feature, but all lists will be incomplete. So, the larger the list, the more things have been left off. It's another avenue to scope creep.

Finally, get people using your product. Whether it's an app or API, get someone using it a soon as possible. This helps to alleviate the problem of software being ephemeral. Once you have a user, you have something very concrete to discuss. If the software has missed the mark, you can discuss exactly why. If it's spot on, you can discuss the next beneficial feature.

Either way you delivered a product, and you've finished a feature.