Dr. Dobb's Journal - February 2009 - (Page 44)

d02ambler_p3ds 12/12/08 7:10 AM Page 44 Disciplined Agility by Scott W. Ambler Agile Package Implementations Commercial off-the-shelf installations are more common than you’d think WHENEVER YOU READ about agility, 99 times out of 100 it is about new software development. Among those rare writings that look beyond software development, perhaps 1 out of 100 describe how to take an agile approach to package implementations. This is truly unfortunate because package implementations, often referred to as “commercial off-the-shelf” (COTS) installations, are common in practice. Capers Jones, in Applied Software Measurement, Third Edition (McGraw-Hill, 2008) estimates that in Fortune 500 organizations, COTS packages account for 35 percent of their total software, for close to 50 percent in medium-sized organizations, and upwards to 100 percent in organizations of less than 100 people. The question then becomes, how can you apply agile strategies to package implementations? Figure 1 depicts a lifecycle for package implementation, using the terminology of the Unified Process to help you to break out of the serial waterfall thinking that is predominant amongst package implementation methodologists. On the surface the process appears to be serial, but that doesn’t mean that your approach can’t be agile. Package implementation projects have the potential for significant bureaucracy—the desire to make a perfect decision, instead of accepting the fact that what you really need is a good enough decision, motivates management to require onerous levels of bureaucracy that do little more than increase overall project risk. The agile strategy is to focus on high-value activities, to do just enough work to address the goals and to avoid needless documentation and reviews. The most important thing that you can do is to put together a team of competent people who can be trusted to get the job done, and if that’s not a viable option for you, then my best advice is to stop the effort right now until you’re able to do that. selected. Ideally, all package purchases should be based on technical, financial, and operational merits, but in reality such decisions are often political in nature. When this is the case, there is little value in evaluating candidate packages. This is true even if your goal is to produce the documentation to make it look as if you’ve followed the process to reach the decision that you’ve already made—this is not only blatantly wasteful, it is ethically questionable. If you really are in a position to select from several options, then you need to base that selection on requirements. This doesn’t mean that you need a detailed requirements specification, but it does mean that you’ll need more than a collection of user stories written on index cards. It’s the need to make an informed decision based on requirements that lead many organizations to believe that you can’t do agile package implementations, but nothing could be further from the truth. The agile approach is to recognize that you need a requirements specification and you should therefore do just enough work to fulfill this need. So, you don’t need a 50-page specification but you likely do need a five to 10 page spec. In addition to understanding your business requirements, here are some additional considerations for your requirements specification: • The technical requirements must reflect your enterprise business and technical architecture vision. The package that you purchase must fit into your overall environment—it will not exist in a vacuum. • You need to ask the vendor what tailoring strategies they support. How you will modify the code and data is absolutely critical to development and long-term maintenance. • Identify the integration strategies that this package supports. The package will need to work with several of your existing systems, and they will only support specific integration strategies. • Ask about the success rate of the vendor. Are you about to purchase a package that 90 percent of organizations struggle to install successfully? • You need to specify your quality needs. Does the package come with a full regression test suite? If not, then that will be a serious problem for an agile team because they expect to have such assets. Once your requirements are in place, you need to identify potential packages. The first step is to do some research online to identify candidates. For larger packages you’ll send out a request for information (RFI) to vendors and ask them to rate their packages against your defined requirements, a step that potentially adds calendar time but could reduce your overall cost. Many organizations want to have at least three packages to choose from but sometimes that’s not realistic. In many situations, there are only one or two viable contenders (if you’re lucky). Adding packages In the Beginning At the start of any project, you must choose the right process for the situation you find yourself in. First, make a buy-versus-build decision, and if you want to buy then recognize that you must change your business processes to reflect those of the package you select. Capers Jones reports that if you need to modify more than 25 percent of the system, then it would be cheaper to build a specific system in the long run. He also recommends that you should really avoid modifying more than 15 percent of a package, and that if the vendor is hostile to supporting you if you do modify the package, then his recommendation drops to 5 percent. Second, choose an initial version of your process and the tailor it accordingly. For example, you’re likely to follow a different process for a $500 package than for a $500,000 package—one process size does not fit all. Assuming that you’ve decided to buy, the next question you need to ask yourself is whether the package has already been 44 Dr. Dobb’s Journal l www.ddj.com l February 2009 http://www.ddj.com

Table of Contents Feed for the Digital Edition of Dr. Dobb's Journal - February 2009

Dr. Dobb's Journal - February 2009 Contents Friday Night Fish Fry Alia Vox Developer Diaries Conversations Computing in the Clouds Software Development in the Cloud Videos and Oracle Forms 10g Parallel LINQ Decoupling C Header Files Effective Concurrency Disciplined Agility Swaine’s Flames

Dr. Dobb's Journal - February 2009

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.