Nexus Events chronology and timing

I'm not sure that a general prescription on what to do could ever really hold.

Shouldn't it be up to the teams themselves to decide what to do, in their situation and context, so that events are conducted efficiently and wasted time is minimized? Might they choose to maximize ongoing communication and collaboration with their representatives, for example?

Hi Dusan, 

I hear you loud and clear. We had those discussions as well.

At the end of the day, as Ian stated, let the teams discuss and decide. 

My suggestion is to bring the teams together, explain them the various meeting and what the recommend order is (and why). Once they understand, facilitate a brainstorming meeting on how they want to do that.

In order for this to be effective, I do that discussion is representatives, not the entire teams. Once you decide on a skeleton, try it for couple of sprints and then meet again to adjust. 

There are so many variables that can affect the decisions, like how distrusted the teams are, whether teams prefer morning meetings or afternoon meetings, whether the Sprint end is relatively or stressed, and so forth. 

Although I'm not using Nexus exactly (but other scaled up framework that we have developed at Avay) - most scaled up frameworks that have Scrum as the foundation act in similar way. So I'll give you what my teams like to do:

Sprints are Wed to Tue. The teams decided they want 'heavy' meetings (e.g. planning) at morning time when peopke are fresh minded, and lightweight meetings (e.g. retro and review) at the afternoon.

Backlog is being split between the teams before Mon (any day is good, representative from the team appear, PO is driving this meeting). Team planning is Mon morning. Sprint review is Tue afternoon. Usually planning should appear after review, as you can't predict what is accepted/rejected which can influence your planning, but the trams are working with the PO to accept items throughout the Sprint, so you have pretty good knowledge on what was accomplished. If part of the review things come up (and they do), then the PO work with the team on final adjustments (in case it affects the coming sprint). Now, retro they wanted to do on Wed afternoon. Again, retro should ideally be before planning, so you can pick up at least one item into the coming sprint. The teams realized that most of the items they pick up are not affecting their velocity. For example, let's do pair programming on task from domain X, let's pick up code review request more frequently so code will be integrated into main branch more frequently, let's change the planning format to make it more light wait, let's bring in UX designer into the next refinement meeting, let's reduce our WIP, let's move our brainstorming sessions into morning time, let's be more strict with our daily timebox, let's assign a person each sprint to trigger the end sprint version, let's assign one person each sprint to review the defects coming in from external teams, let's make sure our automation framework code is being reviewed like any other code in the product, and so forth.

Bottom line, let the people speak up, facilitate the discussion, explain the importance and purpose of each meeting and get it started. Run and then adjust. Use empiricism :)

Good luck,

Erez

@Ian: I am not sure they

Might they choose to maximize ongoing communication and collaboration with their representatives, for example?

because their representatives would be gone attending the NIT meetings...

@Erez, I see what you say, and thanks for describing how your events usually line up etc...

Thanks both for your input, appreciate it. Ultimately, I guess it is then a matter of trust they would do something meaningful in that time...