How I Ended Up as a SAFe Fan!
- Bill Holmes
- 4 minutes ago
- 3 min read
“It doesn’t make sense to hire smart people and then tell them what to do.” Steve Jobs
“Most organizations do not have a technology problem. They have a coordination problem.” Gene Kim
I did not begin my career thinking about Agile or SAFe. My early work was focused on large, high-pressure IT projects delivered through waterfall. And if you have lived in that world, you know exactly how the requirements looked.
Thousands of “the system shall…” statements created through hundreds of elicitation sessions. All of them stitched together with the hope that the final product would match what the organization needed. It rarely did.
Most of these projects were governed by executives who did not understand software but took enormous comfort in the process. A large requirements document felt safe. A detailed plan felt safe. Checkpoints and signoffs felt safe. Meanwhile, the work itself was moving in an entirely different direction.
As the environment changed through new regulations, shifting priorities, and reorganized leadership, the documentation did not. When the project had problems, you were only a change request away from new requirements or a replanned schedule that looked believable again. The cycle repeated itself until the project delivered something that matched the documentation but not the need.
After years of watching that pattern, I went looking for something better.
That search led me to Agile and eventually to earning my PMI ACP. The concepts made sense. Smaller increments. Faster feedback. Flexibility instead of bureaucracy. But there was a problem. The people closest to the work could see how effective Agile was, but management did not share that perspective. They continued to micromanage every detail because Agile appeared to them as a loss of control, not a new approach. And to be fair, the environments they operated in were high risk, highly visible, and unforgiving when things went wrong.
Even when Agile worked, I could not figure out how to scale it.
Scrum of Scrums helped in theory, but it had limitations. I routinely ran offices where project teams were far larger than anything Scrum was designed to coordinate. The gap between team-level agility and enterprise-level delivery was significant, and for a long time I worked around it instead of solving it.
I struggled with scaling Agile for years.
Several years ago someone suggested that I earn the SAFe Certified Practitioner credential. Studying SAFe finally connected the missing pieces: dependencies, architecture, funding, strategy, governance, and all the elements that never show up in team-level Agile conversations.
When I earned the SCP, I believed I understood SAFe.
Then someone asked me to teach a SAFe class.
That was the turning point. I learned quickly that there is a difference between knowing a framework and being able to teach it accurately and consistently. Before you can teach any SAFe course, you must complete enablement. It is a process designed to ensure that instructors deeply understand the material and can present it clearly. Enablement forces you to go further than memorizing concepts. You must demonstrate clarity in how the pieces of the framework relate, why the events exist, how the roles interact, and how the operating model works end to end.
And you take the same certification exam your students take.
My progression from waterfall to Agile to learning SAFe gave me a clearer view of how to use agility to drive software development at scale. The journey was long and difficult, and I want to help others get there with less effort. I am going to try to do that.
My first topic will be foundational. Why Agile emerged in the first place, and why neither waterfall nor team-level Scrum could handle the enterprise challenges many of us experienced.