Engineering Tools for Dev Team

If the non-availability of tools threatens the Sprint Goal, the Development Team should collaborate to try and resource them or to find a work-around. The Scrum Master should support them as far as possible in this, so that the team can focus on development activities and on meeting the Sprint Goal.

If the problem cannot be removed, such that neither the tools can be obtained and a work-around is not possible, then the Product Owner should be notified and alternative plans should be agreed. In exceptional circumstances the Sprint may need to be cancelled, and any value incurred to that point should be secured and released.

Also assume for a moment that the PO is unavailable.

Keep going -- do the best you can and also discuss this at the Retrospective.

P.S. Did the question explicitly state this as an impediment?

Do you refocus the sprint on establishing DT infrastructure or adjust the Definition of done to deliver the increment? what would you do in this situation as SM.

I think the key point from this question is when/if you engage the PO. How much does the team engage a solution before they engage additional support. Self-management.

> Do you refocus the sprint on establishing DT
> infrastructure or adjust the Definition of done
> to deliver the increment? what would you do in
> this situation as SM.

If an adjustment of the DoD is being floated as an option, it's really a question of what the Development Team should do. They are the ones who would be held accountable for any technical debt that is subsequently incurred by the increment. They don't have to accept that responsibility at all, and sprint cancellation might weigh as a serious option. Ken Schwaber has recently proposed the idea of "scrumbling" outside of sprints in order to rectify the situation before sprinting is allowed to recommence.

If an adjustment of the DoD is being floated as an option, it's really a question of what the Development Team should do. They are the ones who would be held accountable for any technical debt that is subsequently incurred by the increment. They don't have to accept that responsibility at all, and sprint cancellation might weigh as a serious option. Ken Schwaber has recently proposed the idea of "scrumbling" outside of sprints in order to rectify the situation before sprinting is allowed to recommence.

Interesting point on "Scrumbling", Ian. I wasn't aware of this concept & will try to find out. However, "outside of sprints" is a red flag for me. It seems like a possible "escape route" for scrum teams to push unresolved issues outside their sprint scope & responsibility/accountability. It also sounds similar to so called "hardening sprint". I might be mistaken as I haven't gone through the the concept except what I read above.

There is concept of "swarming" in agile, which may be one way to tackle nonavailability of tools issue.

I know this is a hypothetical question since it's part of the PSM1 exam but will the business actually allow an acceptancej of the project if there's a lack of dev infrastructure?