Note: This is a continuation of our series on agile development processes written by Peter Varhol - principal of Technology Strategy Research, an industry research firm specializing in software development, testing, and deployment topics. Peter is a nationally recognized writer and speaker on software development topics. He is a former professor of computer science and mathematics, and has graduate degrees in computer science, applied mathematics, and psychology.
I've been making the point that it's not enough for an application developed using an agile methodology to be ready to build at just about any time, and ready to deploy at the end of most iterations. The installer also has to be scoped out, built, and ready to use. The first iteration that is delivered to users should have a high-quality, professional installer.
So what happens if the agile team puts off work on the installer? In other words, the team finishes the iterations needed to put the first, important features in front of customers or users, but doesn't have a professional installation package in which to deliver the software?
Probably nothing. At least not right away. The initial product installation may have been archived off from the build server, or even one of the development machines, and perhaps packaged up into a compressed file. Users simply uncompress the file and let the application files flow into the predefined directories. To make application use a little more seamless, they may have to set a path variable or add a couple of keys to the Registry, but these steps can be documented and provided to users with the software. Installation should still only take a few minutes.
The problems start to appear in the second, third, or fourth iterations of this process, and beyond. Agile methodologies are geared toward getting features to users early, so that the team can get feedback on those features, and learn about any changes to business needs. This means uninstalling the old version, and installing the new one. Because there's no automatic uninstall, users have to manually remove files and any path variables and Registry keys.
Guess what? Even if the agile team prepares uninstall instructions, users will miss a few files, variables, and keys. Subsequent installs may overwrite some of them, or not. So later installations may become a little less reliable, and take more time to uninstall and install.
Pretty soon, the users grow frustrated with the time and effort needed to update versions of an application that is becoming increasingly unreliable. Rather than continue the collaborative process with the agile team, they stay with the last "good" version, or abandon the application altogether.
That response spells failure for an agile development effort. Users are frustrated with a perceived lack of quality and usefulness, while the agile team doesn't get the feedback and direction needed to continue useful development work. Without the quality installation and removal capabilities found in a professional installation development solution, it's conceivable that some agile projects will fall short of their goals.
