Most software companies are embracing agile, but agile is difficult to grasp and implement. For me and the teams and companies I’ve been in, it has been a big help having some guiding principles to align people and steer decisions in the right direction. This article outlines one of my favorite principles.
A better way
After World War II, Toyota had a big problem. They were short on cash and every payment for a car was crucial for survival. The way to manufacture things such as a bolt in the 1950ies was to make a million on them to reduce cost per bolt. Being short on cash, if Toyota would manufacture a million bolts, they would have no money to buy metal, plastic or rubber for the next car. Toyota had to come up with a better way.
Grossly oversimplified, what they realized was that every worker should work on the car to be sold at the end of the day. This may sound obvious, but manufacturing a million bolts to reduce cost per bolt is the absolute opposite approach. Those bolts would lie on a shelf and tie up your cash, and you would have to wait to get the cash back.
Instead, if Toyota manufactured a hundred bolts, it was for a good reason. Those bolts were required to produce the car sold at the end of that day.
The income from the sold car would allow Toyota to buy material to manufacture the next car. Without that income, there would be no money to buy material for the next car.
Due to the lack of cash, Toyota was living “hand to mouth” or “knife on throat”. When you think about it, this sounds very familiar. What other type of company has that same pressure to survive? Yes, a start-up!
Behaviors of a Start-up
You would imagine living from hand to mouth would be a bad thing. How could that stress be helpful? Actually, this mentality lead to a number of super effective behaviors:
- Deliver small things of high value
A startup would never survive big projects, nor projects with lots of bells and whistles that nobody needs.
- Deliver early and often
A startup would never sit on new features for months before delivering them. They deliver things many times per week to get an income now, or they might not survive another month!
- Move fast
They try to do experiments to learn fast, deliver together across the technology stack, don’t build inventory and so forth.
This is actually the absolute opposite of what many big companies do. They have their core products that bring a steady income, and that security might make them complacent. On the other side of the spectrum, small and fast companies struggle for survival, and that drive forces them to disrupt and quickly become highly competitive in a field. More often than not, there’s not much the big and slow company can do about this.
Toyota’s story has several key learnings that software development can benefit from. In software, when we deal with knowledge, the resource at hand is primarily your time and code written. Toyota produced a car of great value to the customer. In software, the value lies in deployed features or improvements that make customers happy, that customers are willing to pay for, or things that we can learn something from. There is little value in software that hasn’t been deployed, so we need to get our things into the hands of the customer as fast as possible! Nobody pays for software in a branch.
Just like Toyota, when we start working on something, we should always strive to deliver something of value as soon as possible. Thus, in order to create something actionable from our learnings from Toyota and Start-ups, I came up with the following principle:
Never start working on anything, unless you have a plan on how to deliver something valuable within a few days.
Keep in mind that value could be customer happiness or internal tooling, but also more subtle like critical learnings and risk reducing activities such as integrating sub-systems of a large project.
To help you in your daily work, we’ve summarized the principle and some additional guidelines in a free PDF guide for you to put on the wall.
Why is the principle so powerful? Because it naturally helps you avoid several types of waste that lowers your throughput and speed.
For example, if you run in one direction for months, you will inevitably deliver something that is not quite what the customer wanted. This leads to re-work, which lowers your speed. You need feedback from the customer, and the best way to get this is by delivering often and measuring!
A similar type of waste comes from long-lived branches. We’ve all had branches go stale, which meant they were super difficult to merge, or was never merged at all. This leads to throw-away work. Following the principle, there’s no way you find yourself with a six-months old branch with code you have to throw away.
Another type of waste comes from doing too many things in parallel. Parallel development means longer time to completion of things in progress. The lack of focus introduces delay which makes the customer unhappy. It will also make the developers unhappy since our greatest joy is to see our software in the hands of the customer. The principle avoids delays from parallel development almost entirely, but to make it explicit, we can use this corollary:
Never start working on anything, unless your have finished your work in progress!
Actually, the principle helps you avoid many many other types of waste which we won’t be discussing here. That and the waste mentioned above can be quite subtle to track down. In a later article, I will give you a superb tool for finding and eliminating waste!
Having this principle in the back of my mind has helped me a lot and guided my decisions towards smaller, faster and more valuable deliveries. When in doubt, it can be used to root out the most valuable thing and help you deliver it in days. If you and your team keep it in mind, I’m confident it will help you as much as it has helped me!
Don’t forget to download the free PDF guide for you and your team.
Please let us know in the commentary what your biggest pain-points are when you’re trying to deliver value fast.