My take with Katina Stefanova on Coronavirus and how silicon valley can step up here.
#coronavirus #coronaviruschina #innovation #venturecapital #startups
Wednesday, February 26, 2020
Tuesday, February 18, 2020
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).
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).
Friday, February 14, 2020
Agile and automotive: McKinsey's take is wrong
McKinsey recently published an article on software in Automotive: https://www.mckinsey.com/industries/automotive-and-assembly/our-insights/mastering-automotive-software-launch-excellence?cid=soc-web
Here's what they say about it:
The McKinsey Center for Future Mobility just released the article "Mastering automotive software-launch excellence". In the article, we provide an overview of the escalating role of software in the growing launch problems, analyzing its root causes and providing two solution approaches following the launch excellence framework. We, then, dive further into how automotive players can crack the code on superior launch performance by reducing complexity and increasing robustness in embedded software development. More of our latest thinking on www.mckinsey.com/mcfm.
My take:
Frankly, I think McKinsey missed it here and their analysis here is a bit dated, misses the major challenges, and will never make automotive software of the quality or experience people expect from their computer and phone.
There is a whole cultural and values based analysis of automotive delivery, throughout the ecosystem, that reminds me of many other industries pre-agile (15-20 years ago) and stands in the way of the necessary changes. They have a way of working around negotiation specs and delivery - and view software as a part or sub-system, with a whole organization behind this (finance, program, manufacturing, design, etc). Software isn't 'isolation' or treated as a part, that needs to be spec'd and finished, but an agile mindset of delivery.
Until these barriers come down, software in cars will continue to be the worst part of the user experience, and the few that master it (I'd put Tesla in the lead) will delight their users and find that software is not 'just another part of the car' but one of the key elements of the mobility experience and delivery
Software has never done with half measures, and these recommendations are even less.
Software has never done with half measures, and these recommendations are even less.
Subscribe to:
Posts (Atom)