Explore different perspectives on SAFe, a popular Agile methodology. Discuss its potential pitfalls, reasons for implementation failures, and situations where it might not be the suitable choice.
What is bad about SAFe?
SAFe uses fallacies in estimation. SAFe decreases the agile focus on value in favour of “what management wants”. SAFe decreases the utility of, and the focus on, retrospectives. SAFe is not Agile – it encourages top-down, large-batch planning rather than small, iterative, feedback loops.
Why do SAFe implementations fail?
Doing too much too fast SAFe encourages you to go all in, but what often gets left out is that there is a certain amount of responsibility, (i.e safety, stability, accountability, etc) required to be successful. It’s common to find yourself drowning in new processes, procedures, and unknowns.
Is SAFe a good Agile methodology?
SAFe is fairly good here except that it doesn’t provide a way to do just one or two sprint planning when teams are Agile enough to take advantage of this. SAFe’s planning method is intended for large companies with multiple dependencies. When applied to what it was designed for SAFe gets is good.
What is the critique of SAFe agile?
In a SAFe environment, the defining story points are placed in the hands of management. As a result, critics say, the scale used to measure effort becomes more abstract and basically useless. It also makes individual teams feel that they have no control or accountability over the development process.
When not to use scaled agile?
Not for start-ups – Since SAFe is predominantly a large enterprise agility scaling framework, it may not suit a situation like a start-up, especially if the whole set up is less than say 30-40 people strong– typical of any start-up company.