Lean Startups

Agile approaches are very much about adapting and using short increments when dealing with uncertainty. Starting a new company comes with a lot of uncertainty. Agile principles can help reducing risk and improving the odds of success.

Eric Ries is the inventor/initiator of the “Lean Startup” movement. His concept is to incrementally develop your customers and your business. By running experiments, some people also call them spikes, you learn a lot about the business idea you are working on. By using small increments you avoid spending months or years building a product or offering a service that in the end is fantastic but nobody is willing to spend money on. Eric Ries helps you de-risk your business idea.

A complementary technique is customer development a term coined by Steve Blank. While product development important (your product can also be a service) it is equally important to also develop your customer base. In his book “Four Steps to the Epiphany” he describes this process in details. His book is a work book, so be prepared that you will have to do homework.

Why am I mentioning these two? The work of both of them is based on agile principles. Therefore if you are considering to test one of your business idea then the work of these two authors should be part of your preparation. And both are not limited to new companies. If you are tasked to build that brand-new product in your company then you are basically running a start-up. The only difference is that you run it in the context of an existing company, which can be beneficial (e.g. financial backup) or a hindrance (e.g. bureaucracy).

Mass Customization

If you find yourself in a project where you need to deliver and maintain a large number of customized versions of an otherwise standard product you may want to consider designing your processes in support of mass customization.
There are a number of prerequisites that you’ll need to have in place. For one you need a base product that you want to customize. That base product needs a mechanism in place that allows customizing it. For example you could design it so it supports plug-ins.
Next you need a fully automated process for building the base product plus all plug-ins. Ideally you have a continuous integration solution and an extensive automated and virtualize test environment. The latter allows automatic instantiation of different target environments and testing of various product configurations in those environments.
One option for mass customization is then to create a custom package for each individual customer, e.g. by creating an installer containing the base product and plug-ins for just that customer. While the installer might be a good option for a shrink-wrapped product, continuous deployment in a hosted environment will typically benefit from a different approach. For example instead of packaging different installers, you might have a different deployment for each customer. Only the plug-ins for that particular customer would be included to be deployed in their environment.
You can drive this one step further, for example by providing a web site where your customers can select the base product and the plug-ins they want. If they are self-hosted they would receive the custom installer. If they are hosted their deployment in the hosting environment would be maintained accordingly. This web site could include integration with payments systems or with your internal accounting system, e.g. to check whether a maintenance payment was received.
Alternatively instead of having custom installers or custom deployments, the availability of plug-ins can also be controlled through the use of licensing in the deployed product. All plug-ins are installed but only the ones that were licensed are loaded and available.
Of course there are number of other factors that must be considered, e.g. how to design the process and the product so it can be upgraded without downtime. Once you have this in place, though, you will enjoy a scalable solution that allows mass customization.

Feature Branches and Release Management

In a few previous posts (here, here and here) I described how feature branches can be used to reduce project risk. As you move along there are further ways to simplify the use of feature branches.

For example I mentioned release management branches. Release management branches can be used for the final Quality Assurance (QA) work when preparing a release. Having a separate branch for this has the benefit that trunk (or master or main) doesn’t have to be locked down until the release day. The release management branch is controlled in that all changes that are accept to it, are carefully reviewed and specific to the preparation of the release. The rest of the team – that is everybody not involved immediately in the release management – can continue to commit new work into trunk.

That comes at a price, though. While working on the release management branch, trunk still requires work, e.g. merging new features. Alternatively you can neglect trunk while working on the release management branch. Even better is reducing or even eliminating the need for a release management branch altogether.

As a first step you could reduce the length of release management branches, e.g. from a week to a couple of days. Or you go all the way and just remove the release management branch altogether. This is feasible if you release out of trunk and have tight controls over what goes into trunk (“no junk in the trunk”). For example you could give your QA person the authority to decide when a branch is merged back into trunk. The equivalent in Git could be a pull request and the QA person decides which and when to accept a pull request into master. A review on the branch could be a prerequisite, for example QA could verify whether enough automated tests where written by trying to break the system.

By giving responsibility for trunk to QA and by minimizing the required release management tasks releases can easily be delivered out of trunk (or master). With tight controls trunk/master is no longer a “moving target”. Once you have eliminated the release management branch, the overall branch management and the release management has been simplified. A new release can be made from every single successful build out of trunk/master.