Marc this is very insightful. Indeed, a problem-centric approach is what I usually advocate. This is Theory of Constraints, and I like your principles that leaders go first, and that changes small be incremental but complete. Those are interesting ideas.
I also would encourage people to look beyond the SAFe toolkit. I think it is a mistake to try to "implement SAFe", even if you do it a little at a time. SAFe contains some good ideas, but SAFe alone will not make you Agile, and most likely SAFe is too much structure for your situation and will bog you down - especially when you consider all of the other elements (which SAFe has coopted - like DevOps).
What I advocate is looking for ideas in frameworks and elsewhere; then start with where you are, then identify your biggest sources of pain, try to understand the root cause, then figure out how to address that in incremental steps: and to do that, look to frameworks and other sources (DevOps, Lean, operations research, ...) for ideas - but ALWAYS craft your own approach, and refine/adjust it over time to make things better and better.
I believe these are the thoughts behind the recommended implmentation:
You may need help in convincing leadership that change is needed. SAFe advocates developing a team to guide the movement to SAFe. Federated change agents, which may include some leadership, are trained before leaders to assist with changing processes and cultures, including those of leadership. The problem statement and recommended transformation approach is included as input to the decision to change. This will probably take several discussions - first to agree there's a problem to be solved, next to agree that Agile is the best approach, and last to agree that SAFe is the top option to try.
Trains are constructed prior to the LPM level because it's a pull system: you need a functioning train to accept the goals identified by the LPM level. Trains can start with "clean fuel" by only tackling new work and ingesting them as features or using "dirty fuel", implying some work breakdown rework by the PM, RTE, Solution Architect, team, etc. You've pointed out the benefit of clean fuel. The downside is those who stay with the waterfall work can feel left behind. The decision to inject "clean" or "dirty" work into the train is situational, IMHO.
It's a nice article and definitely got me thinking. Thanks for posting it!
Marc this is very insightful. Indeed, a problem-centric approach is what I usually advocate. This is Theory of Constraints, and I like your principles that leaders go first, and that changes small be incremental but complete. Those are interesting ideas.
I also would encourage people to look beyond the SAFe toolkit. I think it is a mistake to try to "implement SAFe", even if you do it a little at a time. SAFe contains some good ideas, but SAFe alone will not make you Agile, and most likely SAFe is too much structure for your situation and will bog you down - especially when you consider all of the other elements (which SAFe has coopted - like DevOps).
What I advocate is looking for ideas in frameworks and elsewhere; then start with where you are, then identify your biggest sources of pain, try to understand the root cause, then figure out how to address that in incremental steps: and to do that, look to frameworks and other sources (DevOps, Lean, operations research, ...) for ideas - but ALWAYS craft your own approach, and refine/adjust it over time to make things better and better.
I believe these are the thoughts behind the recommended implmentation:
You may need help in convincing leadership that change is needed. SAFe advocates developing a team to guide the movement to SAFe. Federated change agents, which may include some leadership, are trained before leaders to assist with changing processes and cultures, including those of leadership. The problem statement and recommended transformation approach is included as input to the decision to change. This will probably take several discussions - first to agree there's a problem to be solved, next to agree that Agile is the best approach, and last to agree that SAFe is the top option to try.
Trains are constructed prior to the LPM level because it's a pull system: you need a functioning train to accept the goals identified by the LPM level. Trains can start with "clean fuel" by only tackling new work and ingesting them as features or using "dirty fuel", implying some work breakdown rework by the PM, RTE, Solution Architect, team, etc. You've pointed out the benefit of clean fuel. The downside is those who stay with the waterfall work can feel left behind. The decision to inject "clean" or "dirty" work into the train is situational, IMHO.
It's a nice article and definitely got me thinking. Thanks for posting it!