Today’s business software is different in more than a few ways from Ford’s Model T’s. That’s why developers at the turn of the 21st century saw that they needed a new approach to taking on their projects, one that wasn’t based on the assembly line model.
One important question, however, still trips up many businesses:
If agile methodologies like scrum lead to the highest success rates for projects, and scrum does away with static lists of requirements drawn up before the project gets underway, then how do you write a request for proposals?
The short answer is: you don’t. Of course, that raises several more questions, foremost among them is, how do you find the development firm offering the highest value—the one that has the best chance of successfully creating an application that meets all the functional requirements, but at the lowest cost?
The Insanity of RFPs in the Post-Agile Age
One of the main principles of scrum is to focus not on technical implementation but rather on business value. Traditional requirements-lists describe software projects in terms of functionality to be achieved, not business value to be delivered.
You can have an application that fulfills all the functions described in a document written months in the past but still doesn’t bring any value to your company—or at least doesn’t bring anywhere near enough value to offset the costs. You could also end up with an application that works quite a bit differently from what you envisioned at the start of the project but that delivers far more value. This is probably the key insight behind agile methods.
Here’s why old-school requirements lists and RFPs are seductive: they give you a clear, unchanging description of the software’s functionality, so you can shop the list around and let multiple development firms bid for the contract.
But you have to keep in mind that requirements list was drawn up at the time when you and the dev team knew the least about the project—i.e. before you’d even begun working on it. That means that the variable you’re counting on to remain constant is in fact bound to change. And, when those changes occur, any cost estimates based on the original requirements list are essentially moot.
With scrum, you don’t have a requirements list. You have a product backlog comprised of user stories. Those user stories are scored by developers according to their difficulty, and the cost of the development is based on the point total. But one of the main features of a product backlog is that it can change as you learn more about the project and as more user feedback is incorporated.
Here’s the problem: if the plan is flexible, then it’s really hard to hold a bidding war to drive down the cost of the final product.
Treating Your Search for a Software Development Firm like a Recruitment Initiative
First, let's be clear that no one is recommending you ignore cost as you compare candidates for the development project. What is called for instead is a shift in perspective. Instead of asking, "What exactly is this going to cost?" a question that assumes a static list of requirements, you should think in terms of "Approximately how much should I budget in light of what I'm trying to achieve?"
Accordingly, the new approach to deciding on a development company is to treat the process less like a bidding war and more like a search for a new employee. For some companies, the software will be undergoing continuous improvements indefinitely, so the analogy is especially apt. But even if you’re looking for a dev team to take on a single, time-boxed project, the same thinking applies.
You expect any new employee to possess an array of pre-specified qualifications for the job. You need them to fulfill a specialized role in your company. And you want to pay them a salary commensurate to the value they bring to your operations. All of this is true of the software you’re looking to develop as well.
So your first step is to narrow the list of candidate firms down to a handful of the most qualified. Then it’s time to start doing interviews. The questions you pose will probably be similar to those you’d ask if you were interviewing a job candidate. You wouldn’t ask about the cost of any final product, for instance, but you’d ask what a unit of work looks like, and at what rate you can expect those units to be completed.
You will of course want to go far deeper than this in your actual interviews. So we’ve brought together a software development practice leader, a scrum expert, and a project manager, collected their insights on the issue, and put them all together in a guide for choosing a company for your scrum project.
It explains scrum in a little more depth, goes into more detail about the importance of the recruitment approach to vetting candidates, and then offers our suggestions for the types of questions and topics you’ll want to cover in your interviews.
Follow the link below and fill out the form to download your copy. And when you’re done reading, let us know what you think.
Want to learn more about agile software development? Check out these episodes of our podcast:
I'm Aptera's Content Strategist. I've been writing about tech and marketing for 5 years and have certifications from HubSpot and The Content Marketing Institute. A big science and literature geek, I taught college rhetoric and composition while I was still busy going to school for way too long, earning bachelor's degrees in anthropology and psychology, along with a master's in British and American literature. Look me up on LinkedIn.