How do you deal with client-related hold-ups in Scrum?

Question

Most of our projects get held up by waiting on client assets. Working under waterfall, we're often on many projects at once and can work on something else while waiting.

We really want to do scrum "by the book" and have one team on a project at a time so we can really focus on those individual projects. But what happens when we get held up waiting on the client? In some cases, assets not provided by the beginning of the sprint could cause project backlog items associated with those assets to go back into the backlog in exchange for those that actually can be accomplished, but what about when it gets to the point where everything left in the backlog depends on those assets?

Pausing on the project to work on something else would be very disruptive and the team would lose momentum, and waiting around doing nothing until the assets arrive isn't an option.

Answer 1

In Scrum, the client (or its representative, the Product Owner) is meant to work very closely together with the development team and be available practically all the time, precisely to avoid blockers like the ones you describe. This requires a close involvement and much more time and energy from the client's side, which may indeed be hard to understand and accomplish for a client used to waterfall.

If you haven't talked to the client about these issues, do it asap. Raise the general problem on the table and make them understand that it is their eminent interest to find a better solution, otherwise their own project will suffer, and that you both are working together for one common goal: to make the project successful. Be patient though, as it is probably not easy for them to rearrange their schedule and commitments. It may also be necessary for you to adjust your process to help the client help you. Adjustments may include

• shortening or lengthening your sprint to intensify or reduce the level of needed client involvement
• arranging regular meetings with the client at specific preset days / times during the sprint
• adjusting the start / end date of your sprints to allow the client to participate in reviews more actively

In the worst case, if the client is unable to significantly increase their involvement, you may want to minimise waste of time and disruption to team flow by focusing on one project per sprint. So when there are not enough ready stories in project A to fill up your next sprint, you switch to project B for one or more sprints, then return to A once the necessary information is provided. I know it's not ideal, still this way at least you can work in an uninterrupted flow within individual sprints. For this to work well, you must strive though to fully complete all stories and leave the actual project in a consistent state at the end of the sprint (which hopefully you do anyway, in the spirit of Scrum).

Answer 2

In some cases, assets not provided by the beginning of the sprint could cause project backlog items associated with those assets to go back into the backlog

So, you have a problem with a backlog. The sole owner and responsible for the product backlog is a Product Owner. Therefore, you should work on this directly with him. While you can and should contribute to the backlog as well, it is neither your team's nor client's problem per se.

To work with backlog items effectively, you need a "definition of ready". If it is agreed between the team and the PO, then at any moment in time PO can check, are there enough (or not enough) backlog items ready for the next iteration, and take action in advance.

what about when it gets to the point where everything left in the backlog depends on those assets?

If proactive backlog monitoring by PO is being done, and you still have under-populated backlog, then you simply do not have enough scope on that project to fill your capacity.

You have an option of taking another projects on, or helping your PO in preparing the backlog items.

We really want to do scrum "by the book" and have one team on a project at a time so we can really focus on those individual projects.

If you stand by that, you should spend your effort on improving backlog items, assisting the PO (and, by extension, the client). This should keep you busy, especially if you do just enough to keep your next iteration's scope topped up.

Pausing on the project to work on something else would be very disruptive and the team would lose momentum, and waiting around doing nothing until the assets arrive isn't an option.

If you really have many projects with mostly empty backlogs, and you have to switch between them to avoid wasting time, then it looks more like a service, not a project development. In such case you are essentially performing occasional services to one or many customers. Maybe, you should consider other agile approaches, like Kanban, which will be better suited for that (having work-based view, not project-based one).

Answer 3

Well first off let's get rid of this notion of doing Scrum "By the Book". Agile is about continuous improvement. It's about the core values and principles to doing software better. If you can look back at last sprint, month, release and say "we're doing better than the last cycle" then you're doing it right. If you look back and say "we did everything by the book and the project didn't ship." then you're not doing it right.

Now stepping off the soap box I suggest turning this problem around. Right now you're focusing on the client and the projects (as well as getting tied up in "by the book"). Instead focus on the team.

What will make them more the team more effective?

Based on what you've said so far, have you thought about a unified backlog for all your client projects? Instead of focusing your sprints on a specific project, focus them on what the team can do. You might end up working on three different client projects in a single sprint. Yes, Scrum talks about every sprint should be a "shippable" release. But is that serving the team?

One of the advantages of scrum is flexible requirements via a backlog that is constantly being groomed. So when a client gets there stuff together, you can more that work to the top of the backlog.

If you're keeping the team busy, you're producing and the quality is good, then you're being successful.

Another thought would be to move away from Scrum and go to a Kanban approach. Instead of team sprints you have WIP limits for the individual and the team and as each backlog item is completed you tackle the next one.