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):
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
In contrast, traditional software procurement processes consist of the equivalent of a “waterfall” process of software development:
- Interview the user population for needs – a needs checklist prepared
- IT team adds systems and security requirements – a second checklist prepared
- The RFP is documented and passes through legal and other reviews
- The RFP is published and potential vendors notified
- The responses are evaluated with respect to checklist
- The price of the bids evaluated
- The PO issued
- The software installed and customization and integration begins
- The product acceptance issued
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:
What is the team like?
- Is the vendor Agile? How Agile? What best practices have they developed specifically for their software development as it relates to product improvement?
- What is the cycle time for introducing a new idea into the production software? How quickly can a must-have be translated into reality?
- What is the caliber of the team? How strong is the vision that drives the software’s development, as evidenced by the demo? How open and receptive is the team to feedback and new ideas?
What’s inside the software?
- Can you get a full evaluation license, without hesitation or red tape?
- Is the user interface modern and well thought out?
- Does the product meet minimum functional requirements? Does it exceed them? What are the gaps?
- Does the software work well? Is it reliable with at least “4 9’s”? Does it respond quickly and perform well?
- How serious is the team about security?
Is there a customer-centric, collaborative culture?
- Are there examples of customer needs that made it into production? How long did they take to implement?
- How close are the customers to the vendor’s team? What’s their level of interaction? Once a year users-group meetings for customer feedback are so last decade.
- Is there a high level of collaboration internally between sales, support and development?
How are scope creep, mid-cycle changes, and changing needs responded to?
- Business goals, technology, and even basic requirements will change over time – the software must adapt, and quickly.
- The time and effort to make changes is reflected in how adaptable a development process is – greater flexibility means quicker turnaround.
- Software will always have some bugs, no matter what anyone tells you. It must therefore be designed to handle targeted patches and updates, and be able to apply them passively. Users shouldn’t have to lift a finger in order to receive a fix.
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.
