There are more methodologies than you can shake a stick at. All promise to streamline your workflow and deliver quality software, many of which leverage the same old approach to work: estimation and timelines.

I am not saying that timelines need to be replaced entirely. Because they are a necessary evil. However, in my experience, most companies putting deadlines on features and projects use arbitrary figures, not for a valid reason.

What is a valid reason for a deadline?

• Complying with a regulatory or legal requirement
• An event where you’re launching a new feature or product
• A serious bug in your application that is breaking things for users (allowing you to communicate an approximate timeframe for when it will be fixed)
• And a few other things

The truth is most companies aren’t using deadlines in this way. They’re using deadlines to push developers to fit their work inside a timed box.

When you place artificial constraints on something, a few things happen.

• Quality suffers as your developers rush to complete the work
• Work/life balance can be impacted if your developers are forced to work additional unpaid hours to get things done
• The work is most likely not being tested properly
• Your developers are more likely to burn out
• Your culture is going to be negatively impacted
• Developers talk, and word ultimately gets out that your company is poorly managed and stopping short of offering way above market price, you’re going to be low on the list of companies people want to work for

This is where the idea of “shipping when it’s done” comes into play. Instead of focusing on arbitrary deadlines, the emphasis should be on ensuring the work is high quality and meets the customer’s needs.

By allowing developers to work at their own pace and focusing on the outcome, you give them the freedom to use their expertise and creativity to deliver something great. This approach is better for the developers’ work/life balance and mental health and encourages collaboration and innovation.

The benefits of shipping when it’s done include:

• Higher quality work, as developers have the time they need to test and refine the product thoroughly
• Greater job satisfaction, as developers can take pride in their work and feel supported by their organization
• Increased productivity, as developers are not constrained by an artificial timeline and can focus on delivering something truly valuable to the customer
• Reduced technical debt, as developers have the time they need to ensure that the code is clean and maintainable
• Better communication with customers, as they are kept informed of progress and can offer feedback along the way

Delivering more minor features often is a critical aspect of the “ship when it’s done” approach. This allows companies to focus on delivering value to the customer as quickly as possible rather than waiting until a larger project is complete. It also allows flexibility to adjust priorities based on customer feedback or changing market conditions.

By breaking down projects into smaller features or user stories, teams can focus on delivering working software more frequently. This approach helps identify potential problems earlier in the development cycle, saving time and resources in the long run.

The benefits of continuous delivery include:

• Greater agility: By delivering smaller features more frequently, companies can respond more quickly to customer needs and market changes.
• More accurate feedback: Frequent releases allow for more accurate feedback from users, which can help teams make more informed decisions about future development.
• Reduced risk: Smaller releases are less risky than larger, all-or-nothing releases, as they allow for quick course correction if something goes wrong.
• Increased motivation: Developers are more likely to be motivated by seeing the results of their work sooner rather than later. This is crucial for new hires especially.
• Better team collaboration: Frequent releases encourage team collaboration and communication, which can lead to more creative problem-solving and better products.

In conclusion, focusing on delivering smaller features often is a crucial component of the “ship when it’s done” approach. By prioritizing outcomes over time, companies can deliver value to their customers more frequently while fostering greater agility, reducing risk, and improving collaboration within their development teams.

The post It’s Done When It’s Done appeared first on I Like Kill Nerds.