Light processes keep development cycles short and sweet

Short projects are generally easier to manage and deliver than large projects: Fewer things can go wrong, fewer people are involved, there’s less time for scope changes, and so on. Since smaller projects typically involve less risk and fewer problems, they can be managed with less rigor and structure.

For years, there's been a movement afoot to take larger projects and break them down into smaller pieces. One approach is to break a large project into a series of smaller, sequential efforts. In a typical waterfall development project, this might mean beginning a project by doing nothing but analysis and then reestimating and planning for a project that does nothing but design, and then construction, and so on. Another version of this approach is to break down a program into a group of separate but related projects, some of which are executed in parallel and some of which are executed sequentially. However, each smaller project still uses the traditional waterfall process.

The rapid application development (RAD) methodology changed this general approach. In a RAD project, the development is still done in an analysis, design, and construction sequence. However, the goal is not to create the final deliverable in one pass but to start off instead with a partial solution. You take initial requirements, create a high-level and flexible design, and then build a product to show the customer. Based on this product, the customer provides more feedback on requirements, and the team designs and builds this further refined solution. This iterative process continues, usually for three to five cycles, until the deliverable meets most of the customer requirements.

Extremely short cycles deliver code that works
All the light methodologies contain this concept of rapid and short development cycles. In a typical six-month RAD process, you might deliver the first iteration of code in three months, the second iteration in six weeks, the third iteration in three weeks, and any other iterations in the final three weeks. In a light methodology, this approach is taken to the extreme.

With light methodologies, the development cycle is compressed to a few weeks or even a few days. In some instances, the software is updated, tested, and delivered multiple times a day.

How is this possible? Remember that short iterations are only one aspect of light methodologies. Another is having the customer integrally involved in the process. If your customer had one or more representatives totally focused on the project, imagine how you could cut down the delivery times of much of the work you do today. Of course, quick delivery times also imply that each iteration is making only incremental changes to the code. The idea is that you can deliver numerous smaller code updates faster than if you implemented the same number of changes together in a longer release cycle.

Use a rigorous and repeatable testing process
It’s important to note that the whole process of rapid delivery cycles will fall apart if the code you’re delivering does not work correctly. If your first iteration is full of bugs and other iterations come quickly on top of it, the entire product will be difficult to test and the project will need to pause.

Light methodology avoids this scenario by making sure the testing process is rigorous and repeatable (and automated if possible). When you start the iterative process, you have few requirements and few test cases. As you add more functionality, you continue to add test cases to the ones you had before. Every time the programs change, even for minor bug fixes, you always run a full set of tests. Every test case must be successfully executed for every iteration.

You can test more quickly if you don’t have to worry about fully testing thousands of lines of code all the time. If you’re pretty sure the code delivered in the previous iteration is accurate and stable, you can focus on making sure the code in the current iteration is solid as well. This philosophy is referred to as delivering code that works. If the code you deliver does not work, the entire process will collapse.

This approach can be tricky at first. But if you can get the first couple of iterations out, your team will start to develop internal processes and habits that will allow the iterative process to become more and more efficient in the future.

Conclusion
Short development cycles are one of the trademarks of light methodologies. As you can imagine, delivering working code every few weeks with more and more features built in can be a daunting task. When you first start down the light methodology road, this short-cycle approach may be the most difficult aspect to get used to. It requires a flexible mindset, a quick planning and development cycle, and tremendously disciplined testing.