Scrum - Responding to traditional RFPs

Question

Hi all,

I've seen many articles about how to put together Agile RFP's and negotiating agile contracts, but how about if you're responding to a more traditional RFP? Any advice on how to meet the requirements of the RFP while still presenting an agile approach?

A lot of these traditional RFP's request specific technical implementations, timelines, and costs, while also requesting exact details about milestones and how the technical solutions will be implemented.

While I'm sure in traditional waterfall it's normal to pretend that these things are facts, it seems wrong to commit to something like this if you're an agile organization just to get through the initial screening process.

What methods have you used to respond to more traditional RFP's?

Here's a sample one grabbed from google, http://www.investtoronto.ca/documents/rfp-web-development.pdf

Particularly,

"3. A detailed work plan outlining how they expect to achieve the four deliverables within the timeframe outlined. Plan for additional phases of development."

and

"8. The detailed cost structure, including per diem rates for team members, allocation of hours between team members, expenses and other out of pocket disbursements, and a total upset price."

Answer 1

Clients like these things because they provide an obvious set of milestones, which can be tied to payment points. If they have no experience of working with Agile they have no basis for framing a contract with a different way of taking and paying for delivery.

As for your position.... Agile requires a large commitment from the customer in terms of time and other cultural changes. It also requires a great deal of trust between both parties: if you start off with a deception then the project is doomed to failure. So you need to talk to the client upfront, to see whether they are prepared to countenance an Agile approach. If they are amenable then you can start discussing different ways of interpreting the ITT so that you can respond to it truthfully.

Answer 2

Agile works somewhat on the idea of being able to adjust the timescales or the deliverables as you go along, which sounds fundamentally at odds with your requirements.

However, you can still be fairly agile - you simply need to plan "just enough" at the beginning that you can give firm deadlines/deliverables to your customer. Within those deliverables you can be as agile as you like, as long you don't lose sight of the long-term deliverables while you are working on short-term iterations.

We have to do this as we have a mixture of customers. We agree hard deadlines and deliverables with the traditional ones, leaving plenty of contingency in our planning. Then we slot in fully agile tasks for our agile customers, to essentially absorb any spare time in the schedule. In this way we can support both types of customer.

We do, however, have the luxury of our "traditional" customers still being fairly relaxed about the deliverables, so we can get away with a relatively high-level spec, rather than having to plan every last detail before we start. Our approach wouldn't work with typical military customers for example.

The way we achieve this is to plan a couple of agile iterations, and beyond that we keep the backlog as a simple list in priority order. We break tasks down just enough that we can get a reasonable timescale estimate, and then our backlog is able to calculate expected code-complete and customer-delivery dates. For agile customers we can use this to tell them how their future deliverables will change if they make a short-term change. For non-agile customers, we simply lock down the tasks so that they cannot move past their deadline dates, and keep an eye on them to be sure we are on target. If something "has to give" in the schedule, the agile tasks have to move.

The danger with this approach is of course that if we over-commit, our agile customers would suffer as we put aside their work to deliver the non-agile work. But if the planning contains reasonable estyimates and plenty of contingency, it's usually not too difficult to avoid this.

Answer 3

Responding to queries about timelines, costs, and milestones is easier if you have a traditional RFP as opposed to a completely agile project. First identify user stories based on the requirements mentioned in the RFP doc. Then perform an agile estimation exercise on those stories with your team (involving a coach, manager, devs, qa, and ui specialist). Based on the data available from your past projects, you would have your team velocity. Divide the total project story points with the team velocity and you get the project duration / delivery date. If you run a 2 week iteration then you can have project milestones every 6 weeks (based on 3 iterations per release as an example). Do the release planning but leave the iterations planning for later. After every release, the project should be in a condition that if the client would like to push it to production they should be able to do it.

As for the project cost, you may tag each of your team with a dollar amount. For example, if you charge $10000 per iteration for a team of 2 devs, 1 tester, and 1 UI specialist then multiply this number with total number of iterations (calculated above) which will give you the total project price.

Some sort of client education may still be required but you would have covered their basic questions like costs and milestones. Similarly, agile doesn't stop from answering technical questions as long as they are not digging deep into what DB tables/columns are you going to create.

HTH, Aziz.

Answer 4

I started writing this as a comment, but this might make more sense...

Very good question, Todd: I've been wrestling with this one as well. I've had excellent results using an agile approach resulting in a continuously satisfied customer and an extreme reduction in stress and pressure on the devolpment team. On the other hand, I do understand that sometimes (most of the time?) customers need to know how much something will cost and when it will be done to be able to plan. That way it's the contractor's problem if he made a bad estimate. On the other hand, I've often seen that it's the deadlines customers care about more than the price, and agreeing to a deadline based on a waterfall design often translates into a shared unspoken agreement between the customer and the contractor that while both of us know it's ridiculous to assume that a ~10-engineer-year project will actually take 10 engineer-years, we don't talk about it and pretend it will happen.

Let me share a recent experience. We got an RFP with a several hundred page-specification and just a couple of days to provide an estimate. I first balked because the estimate deadline was ridiculous, but then decided to give it a try due to the importance of the project.

A colleague and I performed rough analyses independenly and the last day, compared the two. I still don't know what to think about our findings. Our end estimates were within 20% of eachother. I couldn't believe what I saw so I compared estimate breakdowns and sure enough, our estimates for individual sub-modules were mostly within 30% of eachother.

Now, normally, I would have said we needed months to evaluate this thing so I wouldn't have considered an estimate made in such a rush anything to take seriously. However, now that the 2 estimates match so closely, I don't know what to think of it. I'm sure there's something to be learned from that (as it obviously wasn't a coincidence), but I'm not sure what. Was our estimate on the money? Was it a systematic error? How much weight does it carry?

In any case, after this, I'm getting a feeling that although it's best for both the client and the contractor if they trust eachother enough to set up an agile process, but if not, it's possible to provide usable ballpark figures based on a quickly built waterfall model.

Answer 5

Asking how long the project will take and how much it is going to cost is completely normal and OK. There is also nothing wrong with planning as such. The only problem is confusing plans with reality. What we do is present estimation based on a backlog and our known velocity but don't call it a plan, but estimate. Then we talk about our Agile contract.