The quarterly PI’s are for planning because the most you can reasonably plan for with any degree of accuracy is about 8-12 weeks.
There are no deadlines imposed. You plan what you’re going to work on and how long it will take. You coordinate with other teams for any dependencies they may need from you and when. But you as a developer are responsible for saying how long it will take and when you can have it done.
Even after that, you’re only allowed to plan 2/3 of your time and the final 2 weeks of the PI are unplanned specifically to build in more buffer for you. If you do finish when you originally planned to, that 2 weeks is equivalent to 20% time where you can work on anything you want for the company, training for yourself, etc. It’s a built in reward for being on schedule.
And then as a group you discuss all of the risks that could prevent one of these items from being hit schedule wise. So if something comes up that keeps a team from being able to finish something, everybody was aware of it in the beginning and had the opportunity to try to help address it.
There’s no waterfall to it unless you consider anything that acknowledges dependencies to be waterfall.
Planning for 8-12 weeks at a time is the ideal window that lets you set expectations, coordinate multiple teams and avoid derailment without the idea that you can plan forever into the future. The farther you get from now, the more any plans become pure imagination which is why year long waterfall plans are a joke. It’s entirely possible to plan 8-12 weeks at a time. Especially when the point of the system is to acknowledge that estimates are at best a guess.
There’s a balance between setting expectations that business people can plan around and working in a box without communicating anything other than “I’ll let you know when it’s ready.” SAFe strikes that balance better than anything I’ve seen.
But everything will always boil down to leadership embracing it. Until leadership can acknowledge the fundamental lack of accuracy from software estimates, you’re screwed no matter what the methodology.
> You as a developer are responsible for saying how long it will take and when you can have it done.
Which amounts to estimating software deliverables beyond the scrum window, which will invariably lead to disappointment, which will eventually fallback upon the shoulders of devs. It is impossible for delivery dates beyond the estimation horizon to not start being used by management as an anchor at some point in the near future. It only takes one manager promising stuff for the rest of the management team to try and emulate the savior.
Teams coordination only requires timely backlog priority management and does not need to be planned top-down for days on end with all members of all teams present.
The quarterly PI’s are for planning because the most you can reasonably plan for with any degree of accuracy is about 8-12 weeks.
There are no deadlines imposed. You plan what you’re going to work on and how long it will take. You coordinate with other teams for any dependencies they may need from you and when. But you as a developer are responsible for saying how long it will take and when you can have it done.
Even after that, you’re only allowed to plan 2/3 of your time and the final 2 weeks of the PI are unplanned specifically to build in more buffer for you. If you do finish when you originally planned to, that 2 weeks is equivalent to 20% time where you can work on anything you want for the company, training for yourself, etc. It’s a built in reward for being on schedule.
And then as a group you discuss all of the risks that could prevent one of these items from being hit schedule wise. So if something comes up that keeps a team from being able to finish something, everybody was aware of it in the beginning and had the opportunity to try to help address it.
There’s no waterfall to it unless you consider anything that acknowledges dependencies to be waterfall.
Planning for 8-12 weeks at a time is the ideal window that lets you set expectations, coordinate multiple teams and avoid derailment without the idea that you can plan forever into the future. The farther you get from now, the more any plans become pure imagination which is why year long waterfall plans are a joke. It’s entirely possible to plan 8-12 weeks at a time. Especially when the point of the system is to acknowledge that estimates are at best a guess.
There’s a balance between setting expectations that business people can plan around and working in a box without communicating anything other than “I’ll let you know when it’s ready.” SAFe strikes that balance better than anything I’ve seen.
But everything will always boil down to leadership embracing it. Until leadership can acknowledge the fundamental lack of accuracy from software estimates, you’re screwed no matter what the methodology.