I hope you read the title of this blog post. If you didn’t, go back and read it . . . okay. The ironic thing about the title is most people reading it would say, “Well yeah—Jive is a software company that works with phones, so obviously it wouldn’t have anything to do with cars.” Ah, but here’s the catch: a lot of software companies function very much like car factories. Assembly lines, waterfall production—the similarities are striking.
A quick lesson in the history of car production. The basic concept is the assembly line. Henry Ford, often erroneously credited with the line’s creation, actually improved and popularized the already existing idea. Rather than having one person do all the work on one car, Ford assigned each worker a specific task to do over and over. Workers stayed at their workstations and did their tasks as each car rolled by on a conveyor belt. This cut down on production time, made cars less expensive, and allowed Ford to use less-skilled labor. According to an article from HowStuffWorks, a Model T car could be made every 93 minutes in Ford’s first factory, which resulted in new cars coming off the line every three minutes. As technology improved, the process sped up, but the basic assembly line procedure didn’t change much.
Let’s compare this to the standard software company. Software companies typically follow the waterfall method of production, which mimics an assembly line. A product starts off with one team of people (maybe the designers), who do their thing with it and then push it downstream and over a “waterfall” to the next team (developers), who do their assignment before sending it on. The product continues down the waterfall until it gets to the bottom (i.e. the end of the line) and is pronounced done.
Here’s the problem with the assembly line and waterfall methods: What happens if something goes wrong with the product sometime during production and no one catches it? A car might get fitted with the wrong parts, or a bug could get into a computer program. If the product isn’t checked until it gets to the end of the line, you’ve just wasted a lot of time creating something faulty. And if you’re creating a lot of products quickly (think of the new car every three minutes) and only checking for quality once every, say, thousand, you’ll be deluged with faulty products to deal with.
These methods spell trouble and expense for businesses. Luckily, someone figured that out and came up with a better way. That someone was Toyota. In the late 1900s, Toyota realized that car production could be faster and more efficient if problems were caught earlier. They came up with the catchphrase, “Stop the line so the line never stops.” What this means is that Toyota makes a small number of cars and then stops the line and checks them. If there’s a problem, it’s easy to find and resolve. That way, the production line moves steadily and doesn’t get stalled for ages to find and fix a problem that started back somewhere in the last thousand cars. This process also encourages Toyota employees to be proactive and and engaged in their jobs—they’re told that if they see something wrong, they should stop the line and fix it!
Toyota’s practices were innovative and effective, and people noticed. Some began wondering if Toyota’s process could be transferred to other businesses. And that brings us to software and Jive.
Once upon a time in the recent past, a man named Eric Ries looked at Toyota’s production system and said to himself, “I bet I could make that work for software development.” Ries was a programming junkie and an entrepreneur, and the principles he came up with are revolutionizing the way smart software companies like Jive work.
Many different terms get bounced around for Ries’s work, but for simplicity’s sake, we’re only going to talk about small batches and rapid iterations. Essentially, the small batches bit is the same idea as Toyota’s car-checking process. In software, a large project is broken down into smaller projects, or stories, to be completed in two-week “sprints.” Developers check and account daily for the progress of their stories, and they check the progress of the entire project at the end of each sprint. This way, they can catch and fix bugs early.
The success of small batches is increased by rapid iterations. To visualize how an iteration works, imagine the wire spiral on a notebook. Each loop represents a sprint during which software is designed, developed, tested, and released to customers to use. Since customers continually test the software, if they change their minds about what they want or decide they don’t like something, the problem can be corrected before developers move to the next loop of the spiral. Like with Toyota, this saves time and keeps long-term bugs out of the project.
To conclude, the world is quickly proving the efficacy of Toyota and Ries’s ideas, and Jive wants to push ahead of the game. We work in sprints, test often for quality and for user feedback, and give our employees accountability in getting projects done. Unlike companies whose products tumble haphazardly through the waterfall method, we use small batches and rapid iterations to design, develop, and deploy the best products as fast as possible.
So to return to this article’s title, it might be more accurately stated, “Jive is not the car industry of Henry Ford.” If, however, we’re talking Toyota, we’re completely on board.*
*This article explained how Jive’s processes are different from those of the car industry. Keep an eye out for Part 2 of this article, where I’ll explore how Jive’s culture differs as well.