Now Reading
Addressing Challenges for Infrastructure Projects in Agile/Scrum

Addressing Challenges for Infrastructure Projects in Agile/Scrum

by admin1201October 25, 2017

Based on my experience working with teams and stakeholders on multiple infrastructure projects, here are some of the challenges our Agile teams have faced:

  • Inadequate environment knowledge. Complex environments (multiple hardware/software), interdependencies between systems/components, and lack of documentation create a challenge for teams by impeding productivity.
  • New team member integration. Complex environments, less documentation, and lack of supportive tools are a challenge for new team members trying to be productive within a short period.
  • Epics/story writing or splitting. The inherent horizontal nature (not feature-driven) of work involved in infrastructure systems and decisions involved in architecture usually require long-term considerations. Because of purchasing/budgeting, strict interoperability requirements, support staffing, and knowledge requirements for design decisions, product owners and teams find it tough to think in terms of:
    • Epic/story writing
    • Vertical splitting of stories
    • Intended users
    • Business values
  • Amount of time needed for ceremonies/backlog refinements. Because of the nature of the environment and, in part, some of the above-mentioned glitches, it is sometimes a challenge to convince teams about the significant amount of time needed for some of the ceremonies and backlog refinements.
  • More convincing required to implement good engineering practices. As the scope for implementing any of the good engineering practices widens, and many interruptions occur because of unplanned work (production outages, dependent projects, related bugs), it is a challenge to convince the product owner (PO) and team to implement some of the best-practice engineering practices.

Overcoming the challenges

Factor in unplanned time (emergencies, high-severity production issues, rollouts for external team-owned software, or patches) and ensure that your sprint has a buffer by following these steps:

  1. After each sprint, consider how well the team allocated the unplanned time needed for the sprint. Then adjust up or down a bit for the next sprint.
  2. Consider going with a long sprint length. Increasing the sprint length makes the rate of interruption more predictable because the variance will not be so great from sprint to sprint. Alternatively, go with short, one-week sprints and live with the unpredictability.
  3. A highly interrupt-driven team should make sprint planning a lightweight activity. Sprint planning should be a quick effort to grab a few backlog items the team thinks it can do in the coming week, and that’s that. For many teams, it should be a minimal effort of about 15 or 30 minutes.


Please follow and like us:

About The Author

Leave a Response