Automotive hates agile: Phased delivery and governance

I want to thank my fantastic (twice) former colleague Amin Ariana for much of framework here.

I experienced huge frustration here, and wanted to share thoughts on why.

Two accepted principles of almost any automotive product development are: Phased delivery and governance.

Typically, powerful parts of the organization, that control significant resources will manage both of these, in the name of, "coordination," and "watching the money."

Phased delivery:  Programs are divided into phases, with various interim milestones before full production: alpha car, beta car, pre-production, low-volume, etc.  For each phase, there are a set of requirements, which become more complete overtime. 

This naturally appeals to people because each milestone allows for judgment on what is 'ready' and what is 'behind.'  It also forces decisions (vendors, engineering trade-offs) that otherwise might end up in paralysis or continually pushing for a better deal.

Governance:  By its nature, this is a group of functions that track progress, are involved and often approve major decisions, and apply countermeasures and involvement when they perceive need.  Two of the most common ones in automotive are: 1) vendor approval, and 2) budget/internal hiring.

Effectively, to get access to resources, such as hiring contractors, hiring internally or using other vendor products, someone outside your group needs to be convinced.  While this in theory provides an important counter to 'going rouge' or lack of accountability -- in practice, it gives a ton of power and input to non-experts, who typically set up a process for non-software parts of the business, and then demand compliance in the name of, "I watch the money carefully," or, "I want to make sure it all comes together," and force non-agile into the system.

The challenge here is that automotive is just not set up for agile.  Even if a sub-culture can work this way, there are lots of functions that simply don't care, and gate resources.  They block agile, slow down quick decisions and force large requirements, which are inevitably pulled up at a later date for, "where are we on this?  You gave this to me..."

So, what to do:

Often, when stuck in this trap, people try to work around it.  Thinking, well, I'll just fill out the form, but we can all shake our head in agreement when we say we're agile.  Good luck.

Instead, explicitly opt out of this at the beginning, but propose an alternative.  Include the vendor, governance and other such teams in sprint planning sessions.  Bring them into the tent.  Make sure that the person/people involved is sufficiently senior to actually approve, and not just a token person tracking progress. 

Agile is tough in this environment.  The system rejects it.  There are teams built to reject it.  We naturally want to please people and try to be helpful for their "board presentation on what we're delivering over the next 9 months.  "Just a few bullets."  "Now, a bit more detail, like everyone else has."

Just say no.  Half measure lead to full failure.  Agile means agile.  Set up the whole company for success, or don't bother and accept bad software, just like everyone else in this industry.  And, don't listen to McKinsey here either (per my previous post).