3 questions to ask about agile software development in the automotive industry

The automotive industry’s digital transformation has been incredibly dramatic, both on the road, with new cars packed with tech goodies, and on the factory floor, where the Internet of Things, robotics and artificial intelligence have been adding marked efficiencies to the way cars are produced.

On top of these more obvious developments, consumer trends have changed in that drivers are seeking new models of ownership. In fact, they may not seek ownership at all. Today’s drivers may take a bus to a train, then drive a rideshare vehicle 100 miles, drop off the vehicle and then take a subway in an urban area to their final destination. Auto makers are finding the traditional model of simply building cars and shipping them to the dealer showroom has shifted as these consumer trends emerge.

All of this puts tremendous pressure on automakers and software shops to respond quickly to customer needs and services from competitive companies. Software shops need to use agile development techniques to meet these challenges. Here are three questions companies need to ask about how their software development groups can adapt to this new way of developing applications:

  1. What cultural shift is required? For years software shops at auto makers operated much like the military, in a command and control, top-down model. Today, companies need to create flexible teams of workers from different disciplines who are involved in the software development from the start. For this to work, everyone must contribute and everyone has input into the final product. Former U.S. Naval Captain David Marquet has a famous presentation where he explains that, instead of simply instructing all the men on his submarine to blindly follow orders, he lets the sailors closest to the work make the decisions. The captain then only kept the final decision to fire a weapon at the top of the chain of command with him. These cultural changes earned his group high marks on inspections and he now runs a successful consulting business. Much can be learned from this approach in terms of getting all members of the team to contribute and not be afraid to make decisions. After all, the coders are the ones closest to the work.
  2. Is the organization willing to change its organizational structure and procedures? In the past, software was developed in a step-by-step process and people from each group often didn’t have input into the new software until it was much too late. In an agile model, design, development, testing and operations are involved from the beginning and work out any concerns or issues before it gets to operations and everyone finds out that what was developed won’t work.
  3. What are the outcomes that organizations can realistically expect from agile development? By creating an agile development organization, companies can stay flexible as requirements change while also improving time-to-market. Instead of rolling out complete products, software can be developed in smaller modules. This results in fewer bugs and modules that can be plugged in as the teams develop the products.

Companies often don’t know how to get started changing their development organizations. They are too close to the operation and need a team of experienced consultant to get them to look at the organization from a fresh angle. DXC has the experience with large global organizations to help you build development teams that can scale across your organization, from the headquarters group to the most far-flung sites offshore.

Enrico-Stark-headshotEnrico Stark is Head of Application Development & Transformation Advisory for DXC North & Central Europe.


  1. Hm, that’s pretty intereserting


  2. This article reminded me that the Lean Startup methodology came out from the automotive industry. Thank you.


  3. A few points.

    1. waterfall method worked, and we a smashing success because industrialism required it. It won us WWII, and worked until the next industrial revolution. Electronic networking and microprocessing made this unnecessary, but those two phenomena were brought about by waterfall methods. Don’t get too breathless in hagiography or condemnation–agile processes will give way to something else.
    2. Scrum/scrum, user stories/story points and work sprints can be whatever the practitioners want. Yes, you are correct that Scrum is a flavor of agile, but people make the terms work for them. Sometimes sprints are a week, sometimes two weeks, and sometimes longer. Depends on the team and the products/deliverables. Retrospectives are valuable, as you mention.v


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: