Finding a Partner to Trust - Using Scrum to Create an Agile RFP

October 15, 2008 by peterstev

I just finished helping a customer write an RFP (Request for Proposal) for a software development project. The customer has had some expensive experiences with waterfall style projects, and Scrum had been the key to getting those projects back on course. So it seemed logical to plan Scrum from the beginning. But how do you write an agile, Scrum-Compatible RFP? How do you select a company to implement an agile project? We started with Scrum. Part 1 in the Agile RFP Series; 1. Using Scrum to Create an Agile RFP 2. Contents of the Agile RFP 3. Selecting an Agile Outsourcing Partner Google was remarkably unhelpful with this problem. The top links all pointed to a paper and presentation from 2003 about combining Use Cases and User Stories in the RFP process. A request to the ScrumDevelopment Group produced no responses. So we were on our own.

Using Scrum

We decided to use Scrum to create the RFP. During Sprint Zero, which only lasted a week, we were briefed by the product owner. Then we created and estimated the product backlog. We reserved a meeting room for the duration of the project, which gave us a place for the burn down charts, task board, and other information that gets hung on the wall in a Scrum project.

The RFP is the Product

We considered the RFP to be a product, so we used the agile workshops originally defined by Mike Cohn to figure out who our readers are and what they want from the document. We discovered we needed two documents: 1) the RFP itself, i.e. a specifications document and 2) a management presentation with project justification. As the product owner wanted to get his hands around the functionality, we started with the RFP. Based on the projected readership and their needs, we came up with a table of contents which included important elements of a classical Project Plan:

• Project Charter in the form of Company Goals, Mission Statement and Elevator Pitch
• Current Situation: How is the problem being solved today?
• Desired Situation: How should the problem be solved with this system?
• Risk Analysis: What has gone wrong in the past and how do we want to prevent that in the future. What are the big non-functional problems that have to be solved?
• Project Management Procedures & Roles and Responsibilities: A description of Scrum and its roles.
• Budget Recommendation: How much is the project allowed to cost based on the benefit it will bring to the company?
• Next Steps: Selecting the Partner

Each entry in the table of contents became a theme for grouping the stories. Each story corresponded to some content in the RFP or an appendix. For example, we had stories like ‘Current Process Diagram’ or ‘Project Management Procedures’ which corresponded directly to (sub-) chapters in the RFP. Sometimes we did have to break stories down ‘horizontally’, e.g. each user interview was a story, even though a user interview produced no content for the RFP. Such stories had to produce a clearly defined deliverable which was useful for creating the final deliverable. Think assembly line, not waterfall. So a user interview story produced a summary of the interview which the team used a basis to discuss the feedback.

Sprint Planning and Demos

Generally we held the Sprint Demos with the Product Owner, but planned the sprints ourselves. So the team was truly self organizing, particularly when it came to planning the work and defining the content of the RFP. Initially, we set the following themes for each Sprint (even though we planned and prioritized after each Sprint)

1. Project Vision
2. Current State
3. User Interviews
4. Desired State
5. Final Document

Retrospective

It didn’t quite work out that way. There was no 'Final Document' sprint. In the Sprint 1 Retrospective, we realized that we should be delivering the RFP incrementally and that there should be a definition of done for what we deliver. So we decided that a Story is only finished when the corresponding information has been integrated into the RFP document and when that chapter has been reviewed within the team for content, spelling and grammar, and the updated RFP is posted on the Wiki. After Sprint 3, we could have given the RFP to potential suppliers after any Sprint (perhaps with a little formatting), and they could have starting the bidding the process.

Scrum for Non-Software Projects

Scrum worked quite well to manage creation of this RFP. By the end of Sprint 3, we had a document in close to final form. There is a special moment of recognition in the Product Owner’s eyes, when he sees that he will get his product as wants it. People who have worked on a waterfall basis aren’t used to experiencing that until much later in the project, if at all. By the last sprint, we were starting to wonder if the additional work we were investing wasn’t just ‘gold plating’, which made it easier to declare the RFP ‘Done!’ Next Week: The Content of an Agile RFP

Permalink