WHAT:
“SAFe Recovery” – is a set of steps (or a process), geared towards a gradual recovery from adverse impacts of SAFe implementation. While SAFe has been the most well-known, effectively promoted and commercially successful framework , for more than a decade, with its deep market penetration backed by large consultancies and golden partnerships with tooling companies, not too many [client]-companies have achieved any real, deeply systemic improvements, by implementing SAFe. On contrary, many companies have faced some significant financial and reputational risk, after spending years and millions of dollars on SAFe implementations, while forecasting to their sponsors and stakeholders a lot of success.
WHY:
An overwhelming complexity of hierarchical layers, communications and processes that SAFe advocates, has prevented [client]-companies from successfully moving towards incremental product development and client centric organizational design. There is a lot of independent/uncensored industry research and experience reports suggesting this, and bringing to light not-so-successful SAFe adoption stories, of companies that moved in the direction opposite of agility (read more here). There is a large volume of references about SAFe and its negative impact on organizational agility, coming from various industry experts around the globe.
Perhaps, you may recognize some of the following SAFe-related anti-patterns:
- General lack of flexibility/adaptiveness
- Overall, organizational complexity and excessiveness of management layers
- Heavy top-down decision-making and command & control culture
- Traditional, top-down, non-product centric budgeting (portfolios, projects)
- Heavy focus on portfolios and projects, as means of managing work
- Complexity of WBS prioritization and estimation
- Hard dependency on project management tools and metrics
- Expensive, cookie-cutting misguidance by large consultancies
- Weak product definition and lack of customer focus
- Big-batch delivery, based on long release cycles (e.g. PI planning)
- Inability to deliver PSPI in short sprints due component-centric team design
- Absence of teams’ autonomy and independence; too much of local management
- High numbers of old roles with new titles
- Poor recognition of authentic agile roles (SM, PO)
- Low percentage of real full-stack developers; mostly, component developers
- Lack of agile engineering practices (ATDD, TDD, BDD)
- Low code quality and heavy/expensive integration (CI/CD)
- Highly complex vocabulary of terms and definitions
HOW:
We also realize that such a recovery process could be lengthy and frictional. Therefore, our recommended approach is deep and narrow and involves a few initial, critical steps, such as doing an organizational assessment, getting an informed consent of executive leadership, conducting structured training (if necessary), later followed by coaching and consulting support. Our big focus is on product centricity/business agility. We have a lot of experience in this area.
Importantly, we also understand that because the time, effort and financial investments that companies have made in SAFe (a.k.a. “sunk cost”) were significant, there could be some discomfort and hesitation to acknowledge that things did not work out as well as they were expected. We get that. We are all humans and sometimes make mistakes.
We recognize the important psychological aspect of this and are prepared to work with companies and individuals on how to make gradual improvements, while protecting everyone from shaming, blame-gaming and fear of repercussions.
If you are looking for help or are interested in learning more about the approach, please reach out and ask.