Every proposal is a unique piece of Agile work
In companies like ours, Agile is not always easy to put in place. As we have strong contractual commitments with our clients, we need to define the clearest plan beforehand so that we can ensure that there are benefits on both sides before doing a project. That said, we already use Agile with many of our clients, even though most of our projects still use more “traditional” methodologies.
However, there is an area in which we are fundamentally Agile without even thinking about it: the response to a request for proposal. Indeed, we have many different competencies at Capgemini, but we also have different schedules, time scales, clients and cultures that we need to mix in order to build the best answer to our clients’ needs. Usually, the team builds itself up from the business and/or technical leaders’ networks. A lot of people get involved and it is often hard to define the scope that everyone should look at and agility can sometimes become chaos.
SCRUM for dummies (skip this part if you are already SCRUM literate)
In a nutshell, SCRUM is a project management process that has been designed to help teams to become Agile. It has been conceived with simplicity in mind so that it is easily accessible and anyone can get its purpose within just 15 minutes. There are only three concepts to grasp with three items each.
SCRUM has three roles:
- The facilitator is called the SCRUM master; he is the project manager and helps the team in delivering value to a product owner.
- The product owner is in charge of defining the scope of a project and prioritizing the features for the team to work on.
- The team represents every person working on the delivery of a project.
SCRUM has three deliverables:
- The product backlog is a prioritized list of features to be implemented. It is the heart of the process. The goal of SCRUM is to optimize the capacity of a team to deliver the items of this list.
- This list can be broken down in a sprint backlog which describes all the tasks to be done during an iteration. These tasks are a detailed breakdown of the features that have been identified as the highest priorities in the product backlog.
- The burndown chart tracks the progress of the team during an iteration (also called sprint). The SCRUM master can easily check the velocity of the team from the burndown chart.
SCRUM has three ceremonies
- The daily stand up happens every day and every member of the team has to tell the team what he did the day before, what he will do during the day and to describe any blocker he might have. This meeting is usually held in the morning and everybody stands up so that the meeting doesn’t last long (15 minutes max.).
- The sprint planning happens at the beginning of each sprint. The team breaks down each item of the product backlog into tasks until there is not enough bandwidth in the team to add a new item from the list.
- The retrospective happens at the end of each sprint. It gives a chance to the team to analyse how the sprint went. It identifies the good parts and the bad parts and proposes enhancements for the following sprint. It provides a simple framework for continuous improvements.
Applying SCRUM to proposals to structure Agile.
At Capgemini, we already have detailed guidelines for proposals which describe all the items a team has to provide to meet the quality expectations of our group. Therefore, our product backlog is nothing but this existing list. The product owner is obviously the client who requested the proposal. If some of the points in the request are unclear, the team will ask the client for details and prioritisation. The SCRUM master is either a project manager involved in the team or the business/technical leader described in the introduction. Project managers tend to have the right skill set to facilitate meetings and define good KPIs but it is not mandatory to have one involved.
There are three levels of maturity a team can go through to improve the proposal.
- The lowest level involves only the product backlog and the daily stand up. Having everyone committing to a piece of work everyday and reporting on problems solve a lot of issues which usually pop out only at the very end of the process. Using these parts of the process facilitates the day-to-day work.
- The second level involves a sprint planning and a sprint backlog. By increasing the visibility on the tasks, the bottlenecks are identified very early in the process. The day to day work is also easier to track as the sprint burndown gives an obvious status of the remaining effort. This level focuses on optimization.
- The third level involves all the SCRUM elements, especially the retrospective. By identifying what went well and what did not go so well, it provides a handful of actions to speed up the following responses and also to increase the quality. Using all the aspects of SCRUM improves capitalization.
Of course, the bigger the subject is, the higher the maturity level should be.
At the moment, the usage of SCRUM for the responses is still experimental; however, the few experiments gave encouraging results and people from different cultures and even different companies (as partners got involved) worked seamlessly together. This type of initiative can be applied to a lot of situations where agility is natural but where you want to go from a process that just work to a process that continuously increases efficiency and enables capitalization. Moreover, supported by web 2.0 technologies like google docs or yammer, the work can be even smoother, but this will be the subject of another post…