So it’s not very surprising to hear people compare him to “Iron Man”.
But how does this relate to Agile Software Development?
Let’s break down the Agile Manifesto, line by line, to see where Musk puts us to shame (we’ll use electric cars from Tesla Motors as ongoing examples).
“Individuals and interactions over processes and tools”
An office where both design and engineering sit side by side?
A place where equal weight is placed on both design and engineering?
That makes for some real cross-functional teams. Dependencies are easy to fix when the person with the solution is in the same room as you.
Musk knows that the old way of thinking doesn’t quite cut it when you’re trying to change the game. He knows that there needs to be an intense focus on two things: the product and the people building the product.
“Working software over comprehensive documentation”
How is that possible you say? It’s a bit like updating Google Chrome.
When you connect to the internet, there’s a quick check done to see if you have the latest version, and if you don’t, it downloads in the background, and then is installed with your next browser open.
That means there’s no need for thick user manuals or encyclopedia-like requirements documents for you to create. Simply sketch, prototype and develop new features, adequately test them (automation helps, see Continuous Integration), and provide an initial prompt to the user when there’s something new. Your customers can continue using your updated software product, without having to do a thing.
“Customer collaboration over contract negotiation”
If Tesla Motors were to negotiate a contract, they would have never developed an electric car to begin with. The 1800s came and went with failed attempts at commercializing electric cars (unfortunately for us). In other words, electric cars are a proven way to destroy your business.
In spite of this, Elon Musk saw that electric cars were the future.
He may not have directly spoken to customers (initially), but he did speak to the world. A zero-footprint car was the aim(or the job-to-be-done). And Tesla Motors was the best solution.
Had Musk opted for a better contract, we would not see the innovation that Tesla Motors has achieved to date. To succeed, innovation must transcend contract negotiations.
“Responding to change over following a plan”
Imagine you find out the perfect commercial design for an electric car battery requires you to use all the lithium ion batteries currently being produced in the world, as they are being made. Bummer, next idea I guess.
Not for Musk — he decided to build a Gigafactory that will produce more lithium ion batteries the entire world was producing in 2013, by 2020. And, at a fraction of the cost (by approximately one third).
So I guess the lesson here is, if life throws you lemons, figure out a way to draw electricity from them.
It’s not hard, it just requires effort.
The above principles and practices are all simple things to execute. Yet so many large (and even small) organizations fail to do so.
Part of it is a lack of self-awareness. Inefficiencies can be hard to spot with a workforce in the 1000s. Another part isn’t though. When there’s a sea of red tape and goals aligned to solely departmental revenue increases, there’s probably a need for you to inject some of practices Musk uses to get Tesla Motors innovating.
To summarize, this how Elon Musk can make us all a little bit more ‘agile’:
- Develop real cross-functional teams
- Hire passionate people
- Ship often with Continuous Deployment
- Find your customers’ goals (i.e. their jobs-to-be-done)
- Focus on changing the world
I couldn’t end this any better than by providing a quote by the inspiration of Tesla Motors himself, Nikola Tesla.
Start bringing positive change to the agile software development team you’re a part of.