Agile Time

Another big item on your shopping list for a successful Agile development is a little less tangible, but the work will fail without it.

Working hours

Decide up front during what hours people will be available. Most of us don't work in a Draconian factory where everyone clocks in at 9:00 and out at 5:30, but we do need to communicate effectively and to do that we need to know when people are available. Agree product-wide core hours and stick to them. Commonly, I'd use 10-12 and 2-4, but that might vary for situations where part of the team works in other time zones.

Stakeholder availability

If you can, be Agile, don't just "do" Agile. That means that all parties involved in the work need to be trained and operate in an Agile manner. However, regardless of what the books say, people in some roles (at least stakeholders and, often, even product owners) cannot be dedicated to the project full time. If that's the case, agree scheduled time slots when they can be dedicated and make sure they stick to them. Assuming there's no travel involved (see "video conferencing", earlier) hold the regular meetings even if there isn't much to say. Everyone likes having unexpected free time in their calendars. If a regular meeting is skipped once it can be clawed back; twice and no one turns up to the third one.

It's a sensible thing to do for each stakeholder to designate a deputy. There will be times when even the most dedicated individual can't make it (due to holidays, illness, etc). Having a deputy means the work can still go ahead, but remind the stakeholder that they need to keep their deputy informed.

Sprint cadence

I'm used to running large scale Agile developments with many teams, but even if you have only a few teams you'll benefit from sticking to a common sprint duration across all teams. Stakeholder time may be rare, so make the most of it by ensuring that sprint demos and other common meetings happen once for the product, not once per team. Common cadence makes these events easy to plan for and significant to miss. Knowing when a feature delivery that spans several team will be ready and having all teams' work entering integration testing at the same time is a great way to reduce stress and rework.