Here we explore some additional risks to SAFe adoption.

This is based on one and a half years of SAFe adoption at a large software vendor, with 20+ teams building one product.

These risks are in no particular sequence. One could also judge that these are generic risks not specific to SAFe, so we explain the relevance to SAFe.

Product Management Ivory Tower

If the project management team sit together, they create an ivory tower. In reality they have little in common . Yes they need a Community of Practice to improve their skills but their priority is with the product teams. So get product managers physically closer to the POs.

Dysfunctional Product Management (Board)

If Product Management is dysfunctional then the impact will be no content for the Release Planning. If there is no content then there is no “meat” for the teams and no need for cross team planning, so there is no need for Release Planning at all! The PO is then left to prioritise small pieces of work with time horizon of no longer than two Sprints. This will eventually result in poor motivation. It will also result in team members “filling” their time with unimportant stuff thus doing things they want to do, not what the team, domain or enterprise needs them to do.

One Single View of Demand

The Enterprise needs one list of all the demands. Not separate lists from Sales, Account Management, Product Management and Support. The enterprise needs to form one common view of what needs to get done.

This also means that the clients and suppliers need to understand and be aligned with the enterprise’s new way of working. Now we get into the area of contracts. These need to reflect “how” the relationship will work and no longer on “what” will be delivered. For example, the client needs to work closer with the teams.


Architecture is necessary to enable the delivery of value. Architecture should not be designed because it is interesting. There has to be a business reason. That support for the business has to be implemented iteratively on SAFe’s architectural runway and not as a big bang. Otherwise one or more of the following may occur:

  • Value cannot be delivered incrementally, it has to wait for the big bang
  • It is likely that the integration of the new architecture will not be possible
  • The new architecture will be full of redundancy
  • By the time the Big Bang is integration, either the product or the clients have moved on.

No Appetite for Risk

The Release Planning for an Agile Release Train (ART) brings together the teams to build a common extension to the product. This may be driven by a client’s project or a strategic product enhancement. The very first ART must have significant management attention. This requires a leap of faith by all involved.


In versions of SAFe prior to 3.0 the last sprint was known as the “HIP”. Now it is just the “IP” for “Innovation and Planning”. The “H” was for “Hardening”. This was for systemwide integration testing. However in version 3.0 “Hardnening” has been dropped. This assumes that full continuous integration testing is taking place. In reality few organisations have this capability. Therefore “Hardnening” still has to happen. Use “Hardnening” to get the entire organisation testing, fixing defects and implementing automation tests.


Existing organisations will already have tools in place. It maybe necessary to introduce a new tool to support SAFe (e.g. WSJF, three layers). In which case it will be necessary to manually keep the two tools in sync or to build synchronisation. Worse, there may also be a back-office invoicing financial system e.g. SAP which will also need to be synchronised. Now, let us add physical boards too and you can see that tooling becomes an major, cross enterprise issue that must be addressed with energy.

Parallel “Ecosystems”

It has to be acknowledged that for a time there will be one SAFe ecosystem and one “old” ecosystem. This may cause conflict so has to be proactively managed by acknowledging that it will be temporary whilst both ecosystems run in parallel. In addition stakeholders may also have to run in parallel, this is especially tricky for client projects, where some benefits are delivered by the traditional ecosystem and some by the SAFe ecosystem.


Visualisation of the Old and New Ecosystems Running in Parallel
(Click on image to enlarge)


Want to read on? Then click here to discover some inconsistencies in SAFe

Are you considering SAFe?

Want to know more about our experiences? If so, then contact us. We’ll be more than happy to hear from you.