Incomplete Development Team

Sprints are indeed to supposed to occur immediately one after the other, but Scrum Teams are also expected to be staffed in a way that allows an increment to be delivered to an agreed Definition of Done. If this isn't the reality, then the team are not in a position to start a Sprint, and they have a duty to make this clear to stakeholders.

Thanks Ian. That makes sense and I think that is what we will do.

This raises an interesting question though: Who should have the final say in determining if a Sprint commences or not if it doesn't make sense to do so?

To me, it seems most likely to be the PO since he represents the Stakeholders and is responsible for maximizing value.
Would be good to know for sure though.

A Sprint can't commence without the agreement of all 3 Scrum Roles: The Development Team, the Product Owner, and the Scrum Master. If any one of them is an unwilling participant then conducting a Scrum Sprint will not be viable. So in a sense all 3 have the "final say".

To me it looks like your team can improve on spreading the knowledge, it is a common scenario when one person consolidates the knowledge and the rest of the team can not proceed. I would encourage knowledge sharing so that in the future anyone can do a work without dependencies.

I agree that encouraging overlap is important and it is something that we are continually trying to improve upon.
However the project we are working on requires a diverse range of specialties. The developers here are T shaped and we have overlap, however some areas are so specialized that it is not always efficient to work this way.

Your point is valid though, I'm sure this happens a lot. Thanks for the advise.

I recommend having a read of Joy, Inc. and seeing how effecting their programming techniques are. They are in stark contrast to what you just said Karl.

Read it with an open mind first! Check out their website too - http://www.menloinnovations.com/our-method/

Hi Tim, thanks for the recommendation but could you elaborate more? I'm not exactly sure what your point is.

Hi Karl,
I agree with the answers about spreading knowledge in your team.
To answer your question "Have I missed something in the Scrum Guide that accounts for this?":

Sprint Planning: "The input to this meeting is the Product Backlog, the latest product Increment, projected capacity of the Development Team during the Sprint, and past performance of the Development Team. The number of items selected from the Product Backlog for the Sprint is solely up to the Development Team. Only the Development Team can assess what it can accomplish over the upcoming Sprint."

Did the team take the capacity into account? If so, they probably would be able to deliver an increment.

I also agree with the importance of spreading the knowledge in the team. But should we expect any team member to perform any task required to deliver an increment? For example should a graphic designer be expected to work on back-end tasks or vise versa? This is not a practical expectation in my opinion.

To address the rest of your post I believe you have done well to show where this issue is addressed in the Scrum Guide. So yes, we assessed the current capacity of the team to deliver an increment, we found we did not have the capacity so the Sprint did not commence.

So you assessed the current capacity instead of projected? Or was the actual capacity different to the projected? We should expect the team to be able to deliver. If there are tasks which only one person (e.g. the graphic designer) can do, this represents a risk (known as scarce skills), as you see right now. Crossfunctional doesn't mean that everyone can do everything, but the team should not be dependent on a single person. They should re-organize if one person gets sick and still deliver something, maybe with tradeoffs which they negotiate with the Product Owner.

My point is that if task A needs to get done, but the guy who usually does those types of tasks is out for 3 weeks on vacation, then someone else should pick up the task, learn how to do it, even if it takes slightly longer.

The really elaborated version of the answer you will understand once you've read Joy,inc and their development philosophy. They might have specialities in development, but they learn what is required to deliver an increment of value.

If Client X says they need Java work, but only .NET people are available, then those .NET people effectively teach themselves Java as they go - which does in the end turn out to be very practical - as now they have people who have good knowledge on both Java & .NET. That is one short example. It is a long term investment which will benefit everyone in the long run.

Ah yes, I should have said projected rather than current.

Thank you Ludwig. I feel like you have approached the difficult situation in a level headed and pragmatic way. I will try this approach should the situation ever occur again.