I promised a picture of the (jokingly) “super duper dependency board runway” (PDB) for our Agile Release Planes (ART) two weeks ago from my amazing uber client people at ESC. Well, here you go.
before the ART 1 and ART 3 PI4 Planning (P4 PIP):
A fractal is a mathematical set that exhibits a repeating pattern displayed at every scale.
Modularity and Fractal behaviors of scaling “Agile” frameworks. Do you see the consequential behavior of scaled Agile implementations as fractal patterns? Shouldn’t they be or are they?
Should a team’s relative estimating be fractal? performance in value and successful outcomes?
Any math nerds want to help out a coach? Does the analogy work?
Admittedly, I’m not smart enough to wrap my head around much more than simple addition and subtraction. I do see the similarities and I am always looking for better ways to describe what we teach. Thoughts?
Aside Posted on Updated on
I encourage all readers to check out the SAFe© guidance article on the subject before reading this article. SAFe© and Scaled Agile Framework© are registered trademarks of Scaled Agile Inc.
An aside about Business Value reflection
Some SAFe© acronyms defined:
Epic Owner (EO), Business Owner (BO), Product Owner (PO), Product Manager(PM), Lean Portfolio Management (LPM), Scrum master (SM), Release/Solution Train Engineer (RTE/STE), Solution Management (SMg), Business Value (BV), Story Points (SP)
In SAFe©, a long-lived ART should come to a state where Business Value (BV) is reflective, but not equal to in any way, of normalized story points at the team level. Read the rest of this entry »
SAFe© and Scaled Agile Framework© are registered trademarks of Scaled Agile Inc.
I am no artist but at least I try. Here are the general guidelines to develop PI Objectives. Try not to regurgitate your teams pulled features as objectives. Think about how your team is going to deliver business value to the customer.