I'm a SAFe certified SPC and RTE. Also a programmer with 20+ years of experience. IMO the only real issue with SAFe is that the quality of trainers have probab

I'm a SAFe certified SPC and RTE. Also a programmer with 20+ years of experience. IMO the only real issue with SAFe is that the quality of trainers have probably become diluted. If you have a SAFe instructor without a programming background to go along with it who can understand how all of the pieces involved will affect the people and the process, you're going to end up with pure by-the-book rigid implementer...because they probably don't know any better. I was drawn to SAFe after posting a lot of venting thoughts on my blog, that got picked up here and somebody on this forum recommended a fantastic book to me. The Principles of Product Development Flow: 2nd Generation Lean Product Development by Donald Reinertsen. https://news.ycombinator.com/item?id=17154355 https://news.ycombinator.com/item?id=17154355 This book is not rigid, nor are the principles within it. I used those principles to very successfully run a development group, but I was failing at consistently involving the business side of the house effectively. I looked around for something more formal that was based on his work and I found SAFe. Going through the training, it's about 80% based on that book. You'll recognize all of the underlying principles. But I took so many classes on it because I wanted to make sure I understood SAFe well enough to know the goals of it's structures so that I knew how to adapt effectively. I don't think a lot of SAFe instructors do that. So here's what you need to know about SAFe. They flat out tell you, you are NOT trying to fit the organization into this structure. You're trying to see how the principles of this structure can benefit your organization. If you want an effectively summed up list of the keys of SAFe from everything I've learned it's this: 1. Continuous Delivery & Deployment are the primary goals of this structure. There is a huge focus on development pipeline automation and all of the efficiencies that come from it. I have no idea why anyone would think otherwise based on comments in that link, because it's absolutely core to the entire process. 2. Prioritization without emotion. SAFe prescribes a formula based approach to prioritization that is essentially a dressed up Return on Investment formula called Weighted Shorted Job First. It recommends structures to get a lot of representatives from the business side of the house to go through and apply relative weights to 3 different factors to establish a Value metric called Cost of Delay and then counts on the technical side of the house to estimate the workload. This helps you prioritize in a way that factors in Opportunity Cost. You have X amount of developer time, if you spend it on this you can't spend it on that. This process is FANTASTIC for everyone involved except the person at the company who is used to getting things prioritized by yelling the loudest. On the business side, everybody has a clear place to have a voice in the company priorities. On the dev side, you never get the "everything is top priority" answer that is so common. 3. Feature Flags. This is one of the absolute keys from a best practices perspective and it also critical for a continuous delivery environment. It allows dev to deploy to production behind a flag rather than hold stale branches while waiting for marketing, product, etc to give feedback, documentation etc. Product gets the benefit of being able to show features to specific clients, gather feedback, etc in a production environment while everyone else can prepare to release when they are ready...without having to bog down development with that entire process. The idea of separating Deployment from Release is hard for a lot of people to wrap their heads around. The biggest complaints that I see around SAFe are that it's too rigid and/or that it's waterfall. It's neither of these things. It's made to be adapted to your company and all it involves is a collection of best practices that work really effectively together. They adopted a lot of current practices, like Scrum, into Reinertsen's work because it's easier for an organization to adopt it if they think they're already doing a lot of it. Each team within a SAFe environment can use Lean, Scrum, Kanban, etc. It's up to the TEAM entirely. Scrum structures are just there because a lot of people are already using them. As for the waterfall bit, I reject this entirely. There's a large group of people out there that seem to think even acknowledging a dependency means you have a waterfall process and I bristle every time I hear it. The PI Planning structure allows you to coordinate team planning over 8-12 weeks. Have you ever been in a scrum environment where the teams didn't have a clear path to coordinating? It's awful. Moreover, the structure allows (and insists) that your developers actually provide the plan. This means nobody else has handed you a deadline and your entire team gets to have a dialog about what can be done in what amount of time. You discuss tradeoffs with management if they ask for the world and they only really need a piece and then discuss how to get that piece. How many environments leave developers out of this process entirely? Just handing you tasks? I'm a huge fan of SAFe because it's goal is to provide an environment where developers can thrive. Every time I see comments about SAFe and ask questions about it, I get responses like "they didn't do that in our SAFe implementation." That's because your upper management nixed it. It's not because it wasn't supposed to be there. Personally, I'm a huge SAFe with Kanban advocate. If you have questions about SAFe at your company or you simply want a second opinion on what you're being told, feel free to hit me up. I'll be happy to answer any questions that I can.