Process needs to serve us and not the other way around!
SAFe is just marketing (though very successful with CEOs wanting a quick way for their organization to become “Agile”)!
The desire for process is super dangerous!
Marty Cagan describes this as the “European Process Disease“. You’re most likely already familiar with the process-quotes from Jeff Bezos, Elon Musk and Steve Jobs just to name a few, but here we go:
I think is is fair to say that these industry icons are not exactly fans of “process people”.
Why are (some) European organizations caught in Process Bureaucracy?
It is though worth noting that Apple, Amazon and Tesla are all digital natives with entrepreneurial CEOs.
Knowing that it is both impossible and unfair trying to find a main cause behind this “European Process Disease”, I’ll give it a try anyway finding at least some of the fragments.
The CFO effect wanting predictability and control with an upfront Business Case
For some (e.g., big CAPEX) projects it makes perfect sense to build a Business Case before starting burning money. What too often happens is that this requiring an approved Business Case has become an auto-pilot reaction. You’ll find this hardwired in many organization’s project process as a mandatory gate-criteria. The funny / sad thing is that this demanding a Business Case also holds true even when the validity of the basis for the Business Case is very questionable.
Some de-facto project management models like PRINCE2© takes this Business Case fixation to a higher level. Everything in a PRINCE2© project is centered around the Business Case. Again – for some projects it makes perfect sense to have this strict Business Case focus in a stage/gate model like PRINCE2© … but probably not for high-tech product-led organizations.
PRINCE2© definitely is something European (British actually). Yes – I know the claim “PRINCE2© can be tailored from the smallest to the biggest project”, but it is still PRINC2©.
The Product Perspective
If we e.g., have decided that a given tough business problem has to be solved, it does not make much sense to demand a Business Case before allowing the product team(s) to do discovery work. How can we at this point in time provide cost estimates to the Business Case, if we’ve not yet discovered the best solution to the problem? And how can we estimate revenue effects, when we do not yet know what solution to serve the customers?
The alternative to requiring a big upfront Business Case covering the full project, is to apply a metered / VC-style funding model. And yes of course – the Product Team might at some point in time seek a major CAPEX budget for e.g., some production capacity. Here it’ll be fully understandable and expected to ask for an actual Business Case. At this point in time the team actually does have the foundation for building the Business Case.
“Are we then not doing any budgeting at all?“, you might ask. I’ve seen examples where budgets for the year are allocated, but the actual funding of the Product Teams are deferred to a metered funding. In contrast to the budget allocation on a project portfolio, this model provides the flexibility to fund what makes most value during the year. It might have been the case (many) years ago that you could plan a project portfolio a year ahead with a fair degree of confidence. That is definitely not the case anymore.
Having been around in many organizations, small to very big, I can confirm Marty Cagan’s observation that we in (northern) Europe have an affinity for processes, tools, templates and checklists.
The general rationale often falls into these categories:
The rationale is easy to follow. The approach to these categories are however very different across organizations. It seems to boil down to how employees are trusted / empowered … or not.
Low trust / mercenary culture
Here you’ll typically find a high degree of process prescription and even internal process policing, demanding formal signed waivers for you being allowed to divert from the mandatory processes. This cook-book type of culture also believes in checklists. The more and longer, the better.
In this type of culture you’ll often find a complex and very bureaucratic and multi-layered project governance.
Motto: the higher we score on the CMMI scale the better, making us a real efficient and lean feature factory, generating Output.
High trust / missionary culture
This type of culture also believes in working smart and using best practices. The core difference is the trust that the employees are able to pick & use relevant elements from the toolbox without having processes strictly prescribed … and being able continuously to develop this shared Pick & Use Toolbox.
Motto: the more we trust our teams and the less obstacles we lay in front of them, the better they serve our customers, creating great Outcome for our business.
The Product Perspective
We want and need a Product Team to be effective and efficient.
Being effective means (for a Product Team) to achieve Product / Market fit. The skilled Product Team will use a lot of methods, templates, good practices etc. in the Toolbox to achieve this. The team does not need to be told (prescribed processes) how to do its job.
Being efficient means (also for a Product Team) doing things the right way. Much of this is what I would label professional competences. It makes perfect sense to share / co-develop good professional practices and to have these structured in a shared Pick & Use Toolbox. You would e.g., not prescribe a software developer to do configuration/version management. You’ll expect that to be part of his/hers professional foundation. What on the other hand makes perfect sense is to share good practices on what works best in the given context.
It makes perfect sense to develop and maintain a strong Pick & Use Toolbox, but think twice if you want to prescribe mandatory processes – and if you do, keep bureaucracy low.. Also consider a more flexible funding process.