We are here to help you plan, prepare, respond, and report on anything that comes your way. Give us a few moments of your time and we'll show you.
Apr 19, 2016Back to Veoci Blog
The Agile Manifesto published in 2001 is now an accepted commandment for software development. Our own adventure with Agile began in August 2000 at GE, where on the SupportCentral project we initiated a 2 week deployment cycle - a new version of the software, complete with bug fixes, updates, languages, and new features, every two weeks. We've continued this practice with Veoci; as of this writing, we're on Version 123, and counting our years at GE, we've been at this Agile thing for 15 years.
With all our experience employing Agile methodologies, we've thought a lot about how software procurement should take them into account when considering products for purchase, and we think that how software is developed can be just as important as the software itself in achieving and maintaining success. When evaluating software, coming up with a checklist of functions after months of interviews is the very antitheses of Agile thinking. With Veoci, as we close in on our 100th customer, we have been through (endured!) a multitude of procurement processes, including many RFPs.
It is apparent that, often, software procurement hasn't kept up with changes in software development, especially for SaaS platforms. Moreover, procurement policies are often outdated and unable to account for Agile software standards - they simply lack the vocabulary to deal with a very rapidly developed, customer-driven change model. Now we do not claim to be experts in software procurement, but we do have a few thoughts on how software procurement processes might benefit from applying Agile criteria to products under consideration. There are four Agile principles (from the Agile manifesto published in 2001):
In contrast, traditional software procurement processes consist of the equivalent of a "waterfall" process of software development:
The time it takes between the first needs checklist and when the software begins to be used is months or even years. During that time, needs and people change; and the software as originally procured may end up meeting the original checklist requirements, but not the evolved needs of today. The iterative process in Agile that meets the user needs is unaccounted for. The customization to bridge the gap and user needs ends up adding costs and time to the project. Is it any wonder that 50% of procured software is never used? The first step in assessing Agility is interaction - understanding the software vendor via regular communication and meaningful interactions, to figure out how the vendor is culturally and technologically attuned to meet the current and future needs of your users. The first interaction must include an upfront one-hour structured demo of the software. Without one, it's like judging a restaurant on the recipes of its menu and never tasting the food. And while getting a taste of what the software is capable of, these are the questions to ask:
Getting a clear understanding of the software development process, and using it as an integral part of the overall evaluation of a product can go a very long way in ensuring a long term, successful partnership. If you insist on open and responsive communication with the vendor, the ability to quickly handle and implement new requirements in the software, and a guarantee that the product won't be outdated the day it's rolled out, then Agile products are your best bet.
Receive all the latest emergency, crisis, and continuity management news, tips, and advice