A SAFe Starting Point
Some critics of the Scaled Agile Framework complain that it is too prescriptive. Generally speaking this comes from people who have not had much exposure to the most recent versions which focus on core competencies instead of specific practices (although those still obviously exist). Yet, oddly enough, I have taught hundreds of people, and the typical followup question is "where do I start?" This is after a class which is designed to answer that exact question.
In chapter 9 of his book Turn The Ship Around, David Marquet describes the mechanism of "Act You Way to New Thinking" by which he means instilling new actions into the organization in addition to and before communicating all of the whys to everyone in the organization. While this approach is certainly something that must be carefully considered and executed, there is obviously merit to that approach as his crew demonstrated with their "three name rule." The same approach can be useful when helping an organization adopt new practices. While the Scaled Agile Framework is principle based, it can still be very useful to have a concrete starting point for new practices. That way members of the organization can focus on what they want to (which is generally work and not the process around the work) while they get accustomed to the new way of working and mastering the principles so they can then adapt the practices themselves based on experience and the underlying principles.
So with that in mind, here is a prototypical calendar for an organization that you can then customize for your own starting point. The calendar will include a bit of explanation and which portions SAFe considers essential and why. The calendar will be built from the Team perspective up to the Portfolio perspective, but that does not mean that it should be implemented that way; the SAFe implementation roadmap remains a very good guide.
Team Events
Two week Iterations start on Wednesdays. Generally speaking Mondays and Fridays are bad days for major meetings due to long weekends, and consultants often leave offices on Thursdays. That makes Wednesdays the optimal day to start so that they can end on Tuesdays.
Daily StandUp (DSU): schedule 30 minutes - 15 minutes for standup and 15 minutes for optional meet after for those who are needed Iteration Planning (Plan): schedule 3 hours to start knowing that it will eventually drop to 60 - 90 minutes Iteration Review (Rev): schedule 4 hours if your team is not continuously demonstrating completed work to the PO for acceptance (which is the better approach); schedule 2 hours when doing continuous acceptance knowing that it might eventually drop to 60 - 90 minutes Retrospective (Retro): schedule 60 minutes and do not allow it to go shorter than 45 (short retros are probably not productive retros) until the team is very mature
This is the basic Scrum calendar. While Scrum does not specify when or how Backlog Refinement should take place, Backlog Refinement is generally accepted as a necessary practice. Experience shows that roughly 1 hour per week appears to be a good amount when the entire team is involved. Backlog Refinement allows the Team to focus on future work, so during the first Backlog Refinement session in the blue Iteration the Team is discussing work for the green Iteration. If everything is clear for a Story then it can go into the Iteration Backlog, but if the PO doesn't have all of the answers, then he or she can do some research before the second Backlog Refinement session. Similarly, during that second session in the blue Iteration the PO and Team have a few more days to clarify the Story prior to Iteration Planning for the green Iteration. And if everything is clear, then the Team can start considering work for one more (but no more than that) Iteration or Features for the next Program Increment.
Backlog Refinement: schedule 60 minutes
Program Syncs
Now that the Team events are scheduled, it's time to look at how the Program events overlay on top of those.
The first few Program events to schedule are the System Demo and the Syncs. The System Demo can lag the Iteration Review by up to one week; one simple schedule option is to have it on the same day of the week at the Iteration Review. In this prototypical schedule that means that Reviews/Demos are taking place on every Tuesday. One Tuesday is the Iteration (Team) Review and the other Tuesday is the System (Program-wide) Demo. The next meetings are the Scrum of Scrums (Release Train Engineer and Scrum Masters), the PO Sync (Product Managers, Product Owners, and RTE), and the ART Sync (RTE, SM's, PM's, and PO's). Why not just start the work week with a sync and alternate separate syncs and ART syncs?
System Demo (SD): schedule 2 hours and adjust up or down over time as needed Scrum of Scrums (SoS): schedule 60 minutes - 30 min meeting and 30 min meet after for those who need it PO Sync (POS): schedule 60 minutes - 30 min meeting and 30 min meet after for those who need it ART Sync (AS): schedule 60 minutes - 30 min meeting and 30 min meet after for those who need it
Intake and Prioritization
This is an area where the Framework becomes less clear. The example Program Kanban board starts with the Funnel where all new ideas are welcome, and WSJF is supposed to be applied to Features in the Analysis stage. However, SAFe provides no information as to what meetings support these activities. Several organizations have adopted "Front Door" meetings where new ideas are welcome and some are turned away (with the intent of returning with sufficient information or a better value proposition or other critical pieces in place). Similarly there needs to be a time for Product Management to meet with System Architecture and Engineering to collaborate on WSJF, and that could be called the Prioritization meeting. For the sake of simplicity, those meetings could be on Monday afternoons after the Syncs (potentially immediately following them with a similar audience). The Intake meeting should be published so that anyone who wants to make a request knows when to show up and what information to bring with them.
Intake: schedule for 30 minutes, but be prepared to change to 60 minutes based on demand and know that it will often end quite early
Prioritization (Priority): schedule for 60 minutes
Conclusion
So there you have it - a starting point for your synchronized cadences for your Agile Release Train. Is this the only calendar that works? Absolutely not! Perhaps the best thing you could do would be to take one look at this and scrap it completely, but sometimes it's a little easier to start from something rather than from nothing. So feel free to use or ignore this sample calendar as you wish.
