Get certified - Transform your world of work today

Close

Addressing Challenges for Infrastructure Projects in Agile/Scrum

6 November 2017

Prabhakar Jha
Bloomberg


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.

 

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: 1 (2 ratings)

Comments

Tim Baffa, CSM, 11/8/2017 8:10:22 AM
It seems that you are promoting a non-Scrum approach to remedy your "infrastructure project" issues. That is fine, and perhaps you should even look at a Kanban approach to your work, which can certainly support Agile.

However, you should not try to frame the experiments, issues, and decisions in this article as "Scrum". They are far from it (30-minute Sprint Planning, varying sprint lengths, sprint buffers).

Also, struggles with overwhelming technical debt, lack of documentation, and an inability to educate people around the benefits of Scrum and good engineering practices are very poor reasons for trying to "morph" Scrum into something that simply masks all of your issues. If you want to work Agile-ly, then you need to begin addressing your issues directly.

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.

 

Newsletter Sign-Up

Subscribe