Always Be Delivering
Counter-intuitively, the right point to release something is when it still feels scary.
The reason is that delivering early and often reduces risks and pushes us past milestones more rapidly.
This is so important that it was included as the 3rd agile principle.
Deliver […] frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
By releasing our work to the world early and often we quickly find out what does and does not work.
Since people are largely tactile and visual, putting something concrete in their hands as early as we can allows us to access our users’ and clients’ most authentic reactions.
This reduces the risk of re-work and time lost. It also gives us the ability to iterate more frequently, growing our product and process in shorter intervals.
We engage early users and see who is serious about the benefits we offer. It also gives people something to talk about.
While there are many great reasons to release early, often, something stops us?
Let’s look at two common blockages:
Perfectionism
This is the voice of fear telling us:
- If I just add X to it, it will be less likely to fail.
- If I don’t add Y, people might criticise the product
Perfectionism never allows for just good enough, it demands that every possible angle of attack or criticism be preempted before release.
A great way to spot this is when continuous new requirements push our release date back. Projects can have shifting requirements, but the story or item you are working on, should not
Real artists ship.
- Seth Godin
Perfectionism does not refer to doing a quality job, but rather crossing the finish line and refusing to stop running.
In order to know where to stop, we need a well defined finish line.
Overbuilding
In order to deliver frequently, we need to take an agile approach, breaking the project into value based milestones and releasing our work at each one.
In doing so, the energy we put into the project comes back to us in the form of user feedback and tangible progress. This is a lot like a performer feeding off of the energy of the crowd.
Without releasing, your team is like a band playing to an empty stadium.
To keep the energy flowing, we need to be ruthlessly focused on only the utmost necessary features for each release.
The online forum Circle is a great example: When I first used the beta version for an online course, there was no way to send other members a direct message (DM). Every communication between users was public, in the form of a post.
If we wanted to coordinate a call or chat, we had to post our emails in the community forum.
It was obvious that members would want to be able to send each other direct messages. This was a glaring hole.
Still, Circle launched without it, because the core value was providing a forum for learning communities, not strictly requiring DM’s.
Even without DM’s their platform offered meaningful advantages over competitors, and so they were ready to release and test.
Though DM’s were quickly requested by users, the platform was still highly valuable without it. They did not need direct messages to launch. It would have been easy to convince themselves that they did. It would have been easy to imagine the future criticism and delay launch so they could include the feature.
When Circle decided to solve the lack of an effective community forum in the online learning space, they knew that users being able to send each other direct messages was not a show stopper, so they released without it.
What non-critical items are you allowing to prevent you from releasing more frequently?
Overbuilding is a common trap, and it leads to lost time and energy—especially motivational energy. If you find you’re often running out of steam mid-project, this is a likely cause.
Start with something simple and observe user behaviors to see what is truly needed next. This prevents building what is unnecessary.
If you have a clear definition of the value you want to deliver and you prioritize the building order, you will find you want to release what you’ve built.
As we wrap up: here are some questions to ask when planning releases:
- What is the most critical value (problem being solved) for the client or user?
- What is the least amount of work that needs to be done in order to achieve that value? (please consider the long term when you seek to minimize work)
- If any user story is expected to take more than 2 working days, can it be broken into smaller value based pieces?
Releasing is important because it provides wins. It gives the team a strong reason to stay engaged. It’s the wind in your teams sails …and sales.