Risks in Agile Projects

8 Top Risks

1 July 2014

Nitin Mittal
Infosys


Identifying risks early in a project and having a mitigation plan in place is one of a project's success factors. Agile projects are no different when it comes to risk management. However, there are a few risks that are more evident in Agile projects compared to traditional Waterfall projects.

In this this article I look at the top eight Agile project risks, based on my experience in executing Agile projects in onsite-offshore models.

There is resistance to acceptance of Agile principles

This is one of the major risks in any Agile project. Project teams (including the customer) do not accept/believe in Agile principles and execute Agile projects with a Waterfall mind-set. This means the focus will be in trying to find shortfalls in the execution method rather than looking at positives or the benefits that come out of it.

Mitigation plan
  1. Train and coach project teams and the customer on Agile principles and frameworks.
  2. Show case studies of successful (and failed) Agile transformations.
  3. Conduct "boot camp" training to induce cohesiveness and spread Agile awareness within teams.


Less experienced team members are not exposed to the customer

In Agile projects, the entire team is expected to talk/converse during various sprint ceremonies. However, traditionally, customer interaction is handled by a senior person on the team, which means less experienced resources are not confident enough to talk/contribute when they are thrown into the Agile project environment. This eventually means commitments are made by one person rather than by the entire team.

Mitigation plan
  1. Plan to execute Sprint Zero from one location (the customer travels to the offshore location, or offshore members travel to the customer's location). Face-to-face interactions early in the project help build rapport and trust.
  2. Understand cultural differences and provide training if necessary.
  3. Encourage team members to talk during sprint ceremonies and back them if they falter initially.
  4. Assign responsibilities to each team member based on user story/functional area/task and make them the owners of their respective areas.
  5. Use the latest technologies (video conferencing, Lync, etc.) for sprint ceremonies to give better visibility and understanding during conversations.


The backlog is not well groomed, leading to poorer use of resources/unnecessary pressure toward the end of the sprint

It is the PO's responsibility to keep a healthy backlog pipeline so that the team's continuity is not lost and so that the team works with the PO to refine the backlog during every sprint. However, in some cases, if the product backlog is not ready for upcoming sprints, teams will be less occupied, even idle, for the initial few days of that sprint. In such cases, the PO may be tempted to add more stories in the middle of the sprint, which will lead to pressure toward the end of the sprint.

Mitigation plan
  1. The ScrumMaster should work with the PO to ensure that the product backlog is ready for at least the next two sprints in advance. Time should be allocated (around 5 percent of sprint time) for product backlog refinement during each sprint.
  2. Include "Prepare sprint backlog for next 2 sprints" as a current sprint task and assign it to the PO. Include this as part of the Definition of Done.
  3. Have a contractual clause in place to address this situation in terms of cost/team retention.


The spirit of Agile is not maintained over time

With proper training and coaching, teams may start following Agile principles and may exhibit self-organizing behavior. However, over a period of time Scrum ceremonies tend to become monotonous and teams no longer look for continuous improvement, becoming complacent.

Mitigation plan
  1. Periodic training/sessions on Agile principles should be conducted.
  2. New trends should be explored and adopted.
  3. A few checks that will keep Scrum ceremonies interactive and fruitful, sprint after sprint, are keeping the Daily Scrum crisp and short, addressing sprint review action items on time, implementing new ideas and methods whenever applicable, conducting Agile games and quizzes, etc.


Teams do not understand Agile estimations and over- or undercommit

Moving from traditional estimation techniques to Agile estimation is (like story point estimation) a big change for a team. If they do not have sufficient training, expertise, or experience, they may end up either over- or undercommitting.

Mitigation plan
  1. Create a reference user story and assign story points to it. Have a session with the team to explain the rationale behind estimation, using this reference story.
  2. Play sample games/exercises with the team, using dummy user stories, before actual sprint planning.


Frequent changes in team composition nullify the team's velocity/capacity

As sprint commitments are based on the team's velocity, and that velocity is discovered over a period of time, changing team composition frequently will result in loss of knowledge, and eventually the team's velocity will change.

Mitigation plan
  1. Prepare a release road map; keep the team unchanged for a considerable period of time before dismantling it.
  2. Cross-train people to address unplanned leave/attrition.


The sprint commitment is not met

One of the common risks in Agile projects is that the team doesn't meet the sprint commitments. This could be due to complex work, unavailability of key resources, faulty estimations, dependence on third parties, and so on.

Mitigation plan
  1. Keep the PO informed of current progress daily and highlight variances as soon as they are found (rather than waiting for the day of the sprint review to declare that the commitment hasn't been met).
  2. Conduct a dry run of the demo one or two days before the sprint review, and align with the PO.
  3. Have any third parties be part of the Daily Scrum if dependencies would delay meeting the sprint commitment.
  4. Commit, in sprint planning, according to available capacity, and request the PO to invite all impacted parties to sprint planning.
  5. Reestimate as soon as you discover that initial estimation were wrong, and reset the sprint commitment.


The team is occupied fixing defects from previous sprints

Once the first set of user stories is delivered to the customer, the team continues to test them, while the next set of user stories is being developed. Many times a high defect rate means the team has distracted its focus from the current sprint goal and instead is focused on fixing defects.

Mitigation plan
  1. Plan for capacity for defect fixing.
  2. In some cases, one separate sprint (the last sprint before release, sometimes called the "hardening sprint") may be run to address defects and fix gaps.
  3. In a very large program, there may be a separate team addressing defects only during specific periods.



Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.



Article Rating

Current rating: 4 (1 ratings)

Comments

Mark Miller, CSM,CSPO, 7/3/2014 9:39:29 AM
These suggestions are helpful as my organization starts the Journey to act and think with agility and adopt the Scrum management framework.
Priya Nagarathinam, CSM, 7/8/2014 1:12:59 AM
Hi Nitin,
Solution Tips for agile in specific the Mitigation Plan is powerful.Thanks,Priya
Nitin Mittal, CSM, 7/14/2014 8:06:24 PM
Thanks Mark and Priya. Happy to know that you found it useful.

You must Login or Signup to comment.


The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.