Learning goals for Certified SAFe® Agilist
- Lead the transformation to Business Agility with SAFe
- Become a Lean-Agile Leader
- Understand customer needs with Design Thinking
- Enable Agile Product Delivery
- Implement Lean Portfolio Management
Personally, I took this exam having participated on agile teams and been a part of scaled agile ARTs in the past. This experience helped greatly when studying for this certification. Experience and going through it is hard to replicate. However, this cert helped me a lot with terminology and various approaches that can be used in a variety of scenarios.
The highest levels of “lean portfolio management” were new to me, so that was an interesting area to learn about. Switching a high-level corporate structure over to scaled agile at a portfolio level seems extremely difficult though. Even if it’s better and you can statistically prove it; I can envision the push back and hesitancy to move in that direction. Having a defined plan with a specific budget and resources, even if it ends up WAY off, is at least concrete (or appears concrete on the surface). Versus a lean budget with guardrails, but still with a lot of fuzziness even after it is approves and begins. It reminds me of DevOps and how trust really needs to be built into the system and earned over time.
I can see how lean portfolio management can be used to deal with the problem of out of control projects. Most corporate folks have seen the scenario of doing lots of upfront planning, estimating, etc. and then get approved for funding. The project owners then build up a team and gather momentum; it’s at this point that things can start to spiral out of control. Roadblocks and issues are encountered that should be viewed as showstoppers, but momentum and difficulty cause them to be pushed off until later.
Maybe the value of the product has greatly diminished for a variety of reasons, maybe the customer actually wanted something else, maybe their are technical issues, etc. Whatever it is, it becomes very burdensome and delayed without a clear path to success. Success and a true definition of done might actually become undefinable. Yet, you can see projects like these continue for years past where it had really become obvious that the project should have been killed off a while ago. However, the momentum with planning, money spent, effort, and people made it hard to do. On larger projects people may have already invested years of their career into it.
Now, it’s easy for me to of course say that scaled agile looks better, but it can likely hit the same issues and even regress into a more formal waterfall oriented project if people aren’t actively paying attention and evaluating the processed being used. There is a natural tendency to want to have control and want to be able to know where things are at; it feels better. It just doesn’t fit well with “most” IT related projects. I don’t think anyone in IT can read the Agile Manifesto and Agile Principles too many times; it really appears that they’ll stand the test of time.