Using the RFP Process to Hire Agile

Posted by Deborah Hartmann Preuss on Jul 23, 2009

Sections

Process & Practices,

Architecture & Design

Topics

Agile ,

Customers & Requirements

Tags

Outsourcing ,

Contracts & Negotiation

It's a common enough scenario: an Agile team finds itself paired with an outsourced traditional (read: un-Agile) partner/vendor/supplier, and the paradigm mismatch wastes plenty of energy for both teams.  Earlier this month we reported on a discussion on the ScrumDevelopment list, where pracitioners discussed how (and whether) to respond to requests for fixed-price bids. Another long-time practitioner has distilled out what he's learned about the topic, and has provided a strategy for creating better RFPs, ones that attract Agile teams: recently Scott Ambler recently wrote about "RFPs the Agile Way -- or -- Fear and Loathing in the Procurement Department."  

Although Agilists generally agree that fixed-price (implicit: fixed scope) contracts encourage inefficient and ineffective behaviour, it's also a reality that many projects still take place under these circumstances. Taking an uncommon point-of-view, Ambler looks at the reality of the whole process, including writing the RFP, not just the response from the service provider:

First the good news with an agile approach to outsourcing. The increased visibility which agile project teams provide to stakeholders make them easier to govern ... The bad news is that this assumes that the customer ... is able to issue a request for proposal (RFP) which reflects the realities of agile development, the topic of this newsletter.

Ah, there's the crux of the problem: RFPs are often written in such a way as to preclude an iterative, just-in-time estimation approach, and many Agile teams don't even respond to them. The key underlying assumption is that if the supplier delivers the requirements as specified, all will be well. Ambler summarizes the well-known issue:: "the customer is unable to accurately define what they want, and even when they do it takes them so long that their requirements change anyway, so it is virtually impossible for the supplier to provide even remotely precise proposals." Ambler calls this charade "unethical" and suggests that, in fairness to the client, an Agile supplier must give the customer other, more effective, options for approaching the work, educating them on the trade-offs and risks.

But let's go back, closer to the root of the problem. In this article, Amber tackles writing the RFP:

... the reality is that somewhere in your organization there is in fact someone(s) in this very position. So, if you can't change your approach then please email this newsletter to them and ask them to think about the agile strategy that I'm about to describe. You can't improve your procurement process if you don't take the first step.

Ambler shows how some fundamental principles apply here: The  Agile Manifesto, Manifesto for Software Craftsmanship and lean development governance . (The article includes, at the end, a reading list for these and other resources). He then outlines what an RFP would look like, to effectively procure the services of an agile development team. It proposes replacing "fixed-price, fixed-scope" with a risk-sharing strategy, based "on a low time and materials (T&M) rate for the supplier with bonuses for continued delivery of high-quality, potentially shippable software"

Ambler admits that his strategy suffers from a couple of potential challenges, but insists that they are fairly straightforward to overcome.

• suppliers generally don't keep people sitting on the bench, ...so it can be hard for them to say exactly who will be on a given project ahead of time, particularly if the customer's decision making progress is slow. (He would advise the customer to have reasonable expectations regarding staffing, but be wary of bait-and-switch tactics). 
• it requires the customer to be accountable for the decisions that they make and to be actively involved with the governance of the project - quite different from the "hands-off" approach that may have been previously used. (Ambler insists that "For outsourcing to work customers must take a hands-on approach where they actively monitor and steer the project." This, apparently, is not the place to save pennies - the risk is too high of a project going off the rails.)

Now, this list is valuable, as developers generally don't (really) know how to write an RFP, and the procurement department doesn't know a Jira from a JUnit. Using Ambler's list as a basis for discussion, it may just be possible to begin the process of feeding back important information to those paid to procure valuable resources for the organization. Ambler suggests that when a team extend its principles of collaboration out to their procurement staff, they might find an openness to dialogue there:

procurement people ... are very intelligent people who know full well that their processes are broken. Unfortunately, they often feel disempowered to change the RFP process, either because they haven't pushed back against their management or because they believe that the suppliers that they're working with don't want to work in an agile manner.

Agile teams are discovering the same thing manufacturers did, in the last century: once you mend the windows in your own house, it can really pay off to go and help your neighbours fix theirs - in this case, internal procurement professionals. Read the full article for details on what an RFP could include to draw Agile teams to your projects.

• Older >