A project can be described as a list of actions, which, when successfully completed will lead to a certain aim. The actions can be performed by one or many persons. Their number may vary from a dozen to thousands. The project can take days, months or years. There are hundreds of methodologies and frameworks that aims to help organize and execute. Each of them is more or less suited for different kind of projects. Some can be mixed. Some provides practices that can be very helpful in many situations. One such practice is:
We all know that one of the most critical and hot times is a project finish. This is the time when whatever outcome has been created it will be released to a client, public or just start working without anyone noticing. During that period major obstacles come to light and are tackled. It is not a rare case that many peoples work is disrupted and hampered due to some new solution introduction. Generally speaking, many projects on its finish have to perform a big jump. Either switch off the old system and turn on the new one or integrate some solution, it is very troublesome, generates a lot of stress and can cause a lot of harm.
One of the core principles that can be used to tackle such problems can be taken from Scrum methodology. A backlog item (if you do not know what it is, think about it as an atomic task) is considered finished when it meets DoD (Definition of Done). DoD may vary depending on the project. For some teams it means that all regression is passing. However, one of the strongest DoDs is that the backlog item has been finished and is running on the production system. Keeping in mind that sprint shouldn’t take more than 3 weeks, it appears that at least every 3 weeks all finished issues has been integrated to the target environment. As a consequence, there is no big jump at the end of the project. No major system switches and changes. Just finishing last issues and rolling them out to production.
How can you use this principle on smaller scope issues? Whenever you are starting any project or task, consider how to divide it into small steps which meet following requirements:
- each step finishes rolling out changes to production, no other roll outs for the step will be needed,
- each step provides value, either for users and the system or allowing other steps,
- after each step, the system is in a stable state, nothing could go wrong if there was no progress for weeks.
The value with which such an approach brings is quite obvious. There are no major changes or integration on the project finish. There are only a bunch of small changes to implement. However, such an approach has to have at least one major drawback: cost. Depending on the project, the cost in comparison to the classic way might be significantly larger. However, this is not always the case.
The above idea heard for the first time might seem impossible. However, almost all issues can be handled in such a way. You only have to find the leverage, or the bridge, that will allow you to implement it. Let’s consider changing the build system of a very huge project with hundreds of modules. The first approach that comes to mind is to work a few months on the migration on side, then apply all changes applied to the build system during that time and perform a big switch. The possibility of major problems and disrupting company work is not a small one. In fact, I am pretty sure that several things will not work out. Migrating module by module might also be not the best solution. Using two different builds system simultaneously for months can be troublesome for developers and add overhead to their everyday job. To apply a principle of small steps, the old build system can be wrapped in a new one. What does that mean? As the first step of the project, we use the new build system in a way that it will call on the old one. Then, step by step, move functionalities to the new build system, transparently for all developers and your CI. All small changes will be rolled out whenever completed. The result: no big risky jump at the end of the project.
Another example might be migration from one source code management tool to the other. If a company has dozens of systems using it that needs to be adjusted and reconfigured, the switch is almost impossible without stopping the whole work for a few days (or even weeks). To handle it and apply the principle of small steps, a bridge can be developed. Such a bridge would automatically migrate on the fly all changes from the old source code management tool to a new one. Thanks to that, all systems can be moved step by step to the new solution, while the whole company’s staff is using the old one. After making sure that all systems are working correctly, the big switch is just to tell the users: everything is working on a new tool, you can start using it now and the old one will be disabled.
Applying the one step at a time practice might save a lot of pain during the end of the project. It might also allow you to execute projects which might otherwise be impossible or very troublesome. However, it has its price. Often a leverage or bridge needs to be developed to allow you to perform small steps and roll them out. Whether to use it or not, as always, depends on your context.