Is Scrum fit-for-purpose for RFi/p response management?
What is your experience with applying Scrum in a corporate pre-sales environment?
The deliverable(s) are typically proposal documents ( strategic, technical, commercial) and value maximization is a fine balance between the value for the bidder ( competitiveness, ease of delivery, financial metrics, time to contract and etc) and the value for the purchaser ( meeting some pre-set requirements, best price, and other procurement evaluation criteria).
Is Scrum fit-for-purpose to manage an RFi/p response ? And to be more specific - is Scrum fit-for-purpose when you are on the bidder's side and you have a set of RFP requirements and a fixed procurement timeline from your customer ( namely, your prospective customer is not running an Agile procurement approach)?
Going to start with this is my opinion and you should wait for others to respond before making your decision.
The Scrum Guide states this
Scrum (n): A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.
Having worked on RFi/p documents from both sides, I'd say that they sometimes can be complex adaptive problems. The key is being able to identify the Product Backlog items and order them in a way that they can be worked. The Sprint actually helps focus the team's efforts to work on specific things instead of trying to do everything at once. I could see that a simple RFi/p could be handled in a single 2 week Sprint but there are some more complex ones that may have to take multiple Sprints.
So, yeah I could see Scrum working. But I question whether there would be enough work to keep a Scrum Team working continuously or whether the Scrum Events would actually provide the needed benefit. In my experience, RFi/p work is not a constant body of work. It comes and goes over time. Maybe if you are a consulting company you would have a constant flow of them as you try to earn contracts or engagements. But even that seems like a stretch to me.
If I were looking at ways of handling the RFi/p work, I'd probably resort to a more Kanban approach of having a list of items that needs to be done, limiting the amount of work that can be in process, and have the team pull work in as they finish work.
Is Scrum fit-for-purpose to manage an RFi/p response ?
Will Scrum Teams be involved in framing that response? Will they be allowed to make their own forecasts and commitments about what is achievable...or can they expect to find that forecasts and commitments are being made for them by others?
Is certainty going to be mis-sold to a client when it is nobody's to offer, and the team's actual competency lies in how they allow uncertainty to be better managed?