5 steps to implement an agile framework in a closed project

When, as agilists, we hear the words “closed project”, it often sends a shiver up and down our spine. However, tackling a closed project using an agile framework doesn’t have to be a terrible experience. In this article we will see how, by applying a few simple steps, we can get a project off the ground and make two seemingly opposing terms come together.

The scenario for which these steps would apply would be a project with a fixed duration and for which the client has been proposed to follow an agile framework in order to obtain feedback as soon as possible that can help to transfer blockages, risks or dependencies and provide the tools to plan new phases.

This scenario is a real challenge for an agilist, as he or she must identify with the client what blockages exist, what agreements are reached and what progress has been made in the development of the solution, in order to correctly manage expectations. The main objective is to avoid additional bureaucracy by achieving total transparency at all times. Let’s see how we could achieve this goal and be successful.

Step 1. Choosing the framework to be implemented.

Normally, being a project with a closed scope, the most appropriate framework would be to approach Scrum as long as there is an incremental value, while the approach would be more appropriate using Kanban in case we have a continuous flow of tasks.

Step 2. Kick-off with the client.

The objective of this session is to establish a shared understanding of the scope of the project, to make explicit what objectives are to be achieved and to define the framework for collaboration with the client, i.e. the day-to-day. This last point is where this step would fit in. The main objective is to explain in detail aspects such as the events, their frequency, their objective, who is required to attend, the dedication of people on the part of the client, and any blockages that may exist (access, etc.). In terms of a more agile approach, a lighter inception phase could be very helpful as a way of replacing this part of the classic Kick-off.

Step 3. Framework go-live.

At the end of the kick-off, at least the daily and first sprint planning should be scheduled. It would be advisable that during the first week, fixed time slots are allocated for reviews, retrospectives and refinements (if necessary, as these can be ad hoc). This will make it easier for the people required by the client to attend. It is important that, especially during the first iteration, special emphasis is placed on remembering what each of the events is for, so that attendees are clear on the purpose and thus avoid irrelevant and scatter-brained topics. If the team is not mature enough, some additional sessions may be required to mentor them on the framework so that they are clear about the objective of each event and the principle of delivering value in each iteration. It is also important in the first iterations to not only work with the Product Owner on what has been decided in the Sprint Planning, but to try to move forward by refining what is to come in subsequent iterations, and whenever the scope has aspects to be defined in more depth. As before, if the team is sufficiently mature, refinements will be ad hoc and frequent, and if not, it will be necessary to establish windows in which to carry them out.

Step 4. Use of the Increment.

The Scrum Guide indicates how important it is to make good use of the different artefacts (Product Backlog, Sprint Backlog and Increment) so that the customer has a clear view of how the project is going at all times. As it is a closed project, the increment takes on the role of the main protagonist. The key is: How do we show the increment in a way that does not involve additional bureaucracy and serves as a unique artefact to explain the global state of the project? By making use of the Sprint Review to show a deliverable whereby stakeholders can see aspects such as the sprint goal, what has and has not been done, overall progress, roadblocks, agreements and even to have formal acceptance of a value increment. Typically, apart from what is visually displayed during the Sprint Review to get feedback from stakeholders, it is helpful to make a presentation reflecting the aspects mentioned above. Using such a presentation as a guide serves several purposes:

• Make progress and blockages transparent
• Mention existing risks so that they can be mitigated.
• Explain the status of the project, assuming possible delays if they are caused by not going at the expected speed, but mitigating possible delays caused by third parties or by the client.
• To serve as a deliverable for the client without the need for additional bureaucracy.
• Metrics to demonstrate progress and team involvement in continuous improvement.

Step 5. Scope changes and agreements.

This step would only be necessary if the customer wants to add new functionalities or replace existing ones to those agreed in the proposal. These are two of the most likely scenarios:

• The customer decides to add a functionality. It should be agreed that another one of the same complexity should be taken out of the scope of the project.
• The customer decides to include a functionality but wants to keep the same scope. In this case the development team will take note of the requirements of the new functionality and make an estimation in effort. A joint planning will be made adding this effort based on the number of iterations needed to carry it out according to the capacity of the development team. Finally, the scope and cost will be renegotiated with the customer according to this planning, involving business development.

It is important to stress that if actions similar to those described in this last step are not taken, the risk of overexertion and non-compliance increases exponentially. Two red lines that must be mitigated with proper management of expectations and negotiation with the client.

In conclusion, following these tips and carrying out an adequate management of expectations and risks, a closed project under an agile framework can be successful and not necessarily require other types of reports and extra meetings.