First release planning event

The corner of a program board. Every team has its own
row, and columns are for sprints. The post-it notes show
the features that the team is working on, while red
strings indicate dependencies.

The trains have left the station! Our two release trains arranged their first release planning event this week. It was a major event, arranged simultaneously in two countries, where teams from most of our functions (R&D, Customer Services, Q&R, Marketing etc.) planned their program increment together. It could have become a gigantic mess, but fortunately we had experienced coaches helping us, so the event went pretty well.

Some lessons learned:

• It may not be easy to involve all functions in your agile transformation, but at least in our case the usefulness of the plan would have been questionable if it had been limited to R&D.
• Try to get everyone to the same location, or do your best to help the remote teams stay on track with the planning. I am still looking for the best tools for remote participation; any suggestions?
• Your first program board is a great eye-opener. If your plan is too complex and fragile with many dependencies between the teams, the board will look like the web of a caffeinated spider.
• Two coaches and one full-time facilitator besides the release train engineer is not overkill for your first event.
• A standard-length release planning event (1½–2 days) can get exhausting for the participants. You can shorten it if all teams create their draft plans in advance; the event can then focus on dependencies, risks and required changes.