The name of the game in software development is velocity. While a variety of opinions exist on what the word “velocity” actually means in the software world, in its simplest form velocity is the rate at which new features are developed and released. Three main factors have the power to impact velocity: methodology, environment, and application stability. Let’s take a closer look at each one and how they contribute toward a high-velocity environment.
Methodology
Chosen development methodology plays a huge role in velocity. Most high-velocity companies use some form of Agile development, where new features are broken down into smaller chunks that can be developed in a relatively short timeframe (usually two weeks). This approach helps simplify the complexity of any one feature and allows the application to grow incrementally. Completed features are then immediately integrated into the larger application as they are finalized. In this way, a “release ready” system is available after every iteration. In a waterfall methodology, features are developed somewhat independently and integrated prior to release. The releases occur less often than with Agile and contain more features per release.
If velocity is calculated as features released into production, Agile wins because features are released as they are developed. If velocity is calculated as features are completed but not released, then waterfall wins because features aren’t integrated until later in the project.
Environment
High-velocity is best achieved in an environment where newly developed features are immediately regression tested against the entire system to quickly uncover any regression defects. This approach, known as “continuous integration”, allows developers to stay focused on the current feature until it is fully integrated into the larger application prior to moving on to the next feature. At a minimum, you would want to perform the regression tests nightly to ensure everything delivered that day works as an integrated whole. If something doesn’t work, the developer can fix it the next day so another integrated regression test can occur the next night.
Ideally, you would want to perform regression tests for each build to give developers immediate feedback on any regression test errors they may have caused with the addition of their new code. One drawback to this method is that as the number and complexity of regression tests grow, it becomes impossible to run a full manual regression test at each build, or even nightly. At that point, you should start thinking about automating your regression tests.
Application Stability
High-velocity cannot be attained or maintained in an environment where developers are constantly interrupted to fix bugs in previously delivered features. Developers need to be “in the zone” and focus entirely on the feature at hand. Taking time to debug and fix defects in previously delivered features severely impacts the number of new features that can be developed and thus reduces velocity.
The ability to fully functional test and thoroughly regression test a feature against the previously developed features limits defects to functional defects within the new feature or regression defects caused by the new feature. In either case, the defect caused by the new feature can be fixed within the development cycle for that feature. This improves and maintains overall application stability.
Selecting the right methodology, creating the optimal environment, and establishing stability for developers all create a ripple effect that can impact the velocity of at your company. For more information on attaining and maintaining high-velocity within your organization, contact an expert at Stonemill Consulting or download our free white paper.
