Pattern Description

A silo organization introduces SAFe in the IT silo. And gets the proof that SAFe is no good.

Issue, Problem, Risk

A silo organization starts to implement Agile in one or more silos, instead of breaking the barriers and thinking of the whole organization as one system. 

No end-to-end view, starting and ending at the real customer.

This approach leaves a very high risk for failing in implementing SAFe, because the implementation starts with an anti-SAFe assumption (a violation of principle #2: Apply systems thinking).

Root Cause

Big organizations tend to split their organization into more manageable entities. Quite often these entities are legal entities. And regularly the heads of these entities (or: „principalities“ AKA silos) have to negotiate with the group about their annual budgets, deliverables, etc. 

Supposed we have a big telecoms operator with a group HQ, including group ICT, operational/national companies responsible for the local markets, all national companies have their own ICT organizations.

When this organization now wishes to implement SAFe, it is very tempting to start with let’s say replacing the Customer Care & Billing vendor in France, and involve (and only involve) the french IT department.

If you do this, the customer triggering your operational value stream is an internal customer, e.g. the french marketing and/or sales department. 

In this case the national ICT organization is treated as an external supplier, the operational value stream of this supplier is „deliver CC&B services“, the development value stream would be called „develop a ‚much better‘ CC&B service“.

Bad luck. Because you stick to the silos thinking which is part of your problem, not your solution.

Mitigation, Remedy, How to avoid

We should look at the Lean-agile principles #2: Apply systems thinking. There we find the third aspect „Optimize the full value stream“ (https://www.scaledagileframework.com/apply-systems-thinking/). 

If you concentrate on ICT, you don’t look at the full value stream. If you concentrate on the ICT of one country this is even more true.

So, first your operational value streams should be triggered by a real customer and ended by having the real customer paying money for the „value“ he/she got from you.

In the example from above, e.g. a real customer is a student entering a shop in Toulouse, wanting to get a new mobile subscription, including a new phone. That’s SAFe’s „Trigger“ of an operational value stream called „new contract“.

This operational value stream ends, when the customer has signed the contract, his/her credit scoring is good enough, and the first payment has been successfully transferred to the organization’s bank account (SAFe lingo: „$“).

In this end-to-end view on the operational value stream quite a lot of departments, teams, etc. are involved, typically you even involve group functions, because credit scoring may be centralized, handsets may be managed group wide, etc. From the top of my head I see:

• Product marketing responsible for the current commercial offers.
• Marketing for advertising material (TV ads, shop looks, etc.)
• Partner management/shop management for shops, shop staff, POS.
• Customer management for validating the customer’s master data.
• Finance for credit scoring, verification of bank data and cash flow.
• Logistics for managing handsets.
• IT operations for delivering POS, CRM, billing, ERP systems.
• External partners for printing & mailing services.
• External partners for quality management and customer satisfaction surveys.

If you now compare this to the „root cause“ example, you might say: I cannot start with this full systems view. Well, if you want to optimize your system, you should do, and actually: you have to. Why?

If you look at the E2E operational value stream, 

• You are able to identify the biggest pain points along the whole process chain.
• You get every involved organizational unit on board.
• You talk about real E2E customer value, not about the details of the requirements specification handed over – sink or swim – from budget authority (e.g. sales & marketing department).