Ship early, ship often

You have a developer and a clear set of requirements to get your project started. Now you need to begin shipping software.

By “shipping” we mean going through the process of implementing your requirements and deploying it to somewhere you can interact with it. The following do not count as shipping:

• Having the code for it complete but not deployed yet
• Having it work on your developer’s computer
• The software being mostly done but with a few loose ends to tie up

For a web application, shipped typically means that there’s a URL that you visit with your browser that will serve your application and allow you to interact with it.

The first thing you should do is ship

Creating a deployment of your software should be the very first thing your developer works on. They can’t deliver any software to you before this step. This should result in an application hosted at a domain name or IP address that doesn’t do very much to begin with.

Setting up a deployment environment for a web application is easy when it doesn’t do anything at all. It becomes more complex with the more features you add to your application. Rather than figure all of the requirements out right at the end of the project, typically a few days before a big launch date, shipping first allows you to solve any deployment problems as you go. You pay this cost up front when you have ample time to spend on them rather than later when you’re feeling greater schedule pressure.

You should ship each and every feature as it’s developed, rather than in one big periodic release.

Shipping means fewer errors

Each change you ask to make to the system requires special consideration when deploying. Does deploying this change require special actions (like running database schema migrations or making configuration changes)? Will it react to production data differently than to development data? Are there any other problems it will have in production that it doesn’t have in development?

Skilled developers will try to foresee these problems to the extent possible but experienced developers know that they’ll eventually miss something. While they will try to prevent problems, they will also prepare for things to go wrong.

If you ship a large feature all in one go, then you have to deal with all the emergent production-only problems in one go. This can result in complex, difficult to diagnose bugs that hamper development speed and otherwise hold your project back.

By instead breaking each task down into the smallest tasks that make sense to deliver and deploy them as they’re developed, you can deal with one set of problems at a time. The parts of the task that deploy without issue will work just fine. The parts of the task that surface problems on deployment can then be easily identified. This makes your development process less error-prone. It also means that when there are errors in production, they’re easily diagnosed and fixed.

Shipping gets you closer to the software you want, faster

One major source of risks in software projects is the gap between the software that you want built and the software that your developer believes you want built. You can take a number of steps (like providing designs/wireframes and clear acceptance criteria) to try and close this gap. However clients often get a clearer understanding of their requirements once they see a first version of their deployed software.

Rather than trying to endlessly perfect the requirements gathering process, we can try to create a tight feedback loop. That means that instead of you giving feedback on the delivered software after a big release, you give it as soon as it’s completed and deployed. If the acceptance criteria has been met then you can immediately create a new task definition based on your feedback and schedule it into the next iteration.

By deploying and giving feedback as each feature is developed, you help to make the desired and delivered software converge in smaller steps. You can make finer-grained course corrections on the development process than if you had to wait for a big release to interact with the software. This is especially important on projects where the major requirements change (which is, in our experience, all projects).

Shipping shows progress

The basic content of client communication on software development projects at the implementation is status updates on progress. The more simply this is communicated the better. Communicating the status of progress on large, complex tasks is strictly more difficult than that of small, simple ones.

From a non-technical client’s point of view, a developer saying that they’re “still working” on a large task is a black box. They have no visibility into the details of the task, so have no way of knowing the real status of progress. Even if given a step-by-step break down of the current progress, they have no way of verifying and giving feedback on the completed steps. They end up having to rely on the trust they have for the developer, which can be eroded if the developer incorrectly estimates the remaining time required to complete the task.

From a developer’s point of view, giving the client feedback on the progress of a large, complex task presents a number of challenges. There may be implementation details that are difficult to explain or seemingly irrelevant to the client that are nonetheless holding the task up. Giving constant status updates may in fact be preventing the developer from concentrating on the task at hand in sufficient depth.

When a lender seeks payment from a borrower on a loan, the best possible status update they can receive is payment. The best possible status update that a client can receive in a software project is shipped software.

By breaking tasks down into the smallest deliverable pieces, the client no longer needs to rely on trust and the developer no longer needs to give awkward status updates. The developer can deliver the software, tell the client how to test it and that is the status update. That’s what shipping early and often buys you.

Help your team ship often

You want your team to ship often. Here’s what you need to do to make that happen:

• Ensure that the developers that will actually implement the software are consulted when writing your acceptance criteria on task definitions. If your developers aren’t given clear requirements, they can’t ship anything.
• Break tasks down into the smallest conceivable pieces that can be shipped individually. You will probably need your developer’s help to do this.
• Give developers time to set up a deployment process that makes shipping software extremely easy to do. They should be able to do it in two or three steps, and it shouldn’t take longer than ten minutes to complete, beginning to end.
• Tell your developers explicitly that they’re to deploy the software as it’s developed. A feature is not “done” until it’s deployed. A feature should be deployed successfully and QA’d before they continue to the next feature in their to-do list.

Summary

• Shipping early and often makes your software project more successful.
• The first thing you should do on your project is set up a production environment that your developers can deploy software to.
• Shipping as features are developed results in a number of benefits:
• It results in less error-prone and easier to fix software.
• It allows you to give more fine-grained feedback on delivered features.
• It gives you more visibility into the progress your developers are making.
• You can help your team ship more often by consulting them during requirements gathering, allowing them to set up a smooth deployment process, and making it clear that they’re to deploy as they go.

Once you become used to seeing consistent (usually daily) forward movement on your project, you become much more confident in your and your team’s ability to deliver on the requirements you set out to meet. You insulate yourself from much of the risk inherent in software projects and so greatly increase your chance of success.

P.S. We’re Happy Bear Software. If you’ve read this far then you should probably sign up for our mailing list to get regular updates from us. No spam, and you can unsubscribe at any time.

Originally published at www.happybearsoftware.com.