First blog post

Just In Time:  Where Agile got its legs

In a previous life, I used to work as an engineer. I used to monitor hundreds of American cars being built every day in automotive plants all over the good ‘ol US of A. These plants were huge. You could walk from one end of the plant to the other, and actually end up walking a couple of miles. Some of these plants were so large, the freight train would actually pull right into the building so parts could be unloaded right there. That’s how big these plants were. There would be millions of automotive parts stored in the plant that would be used over the months and sometimes, over the years.

Then one day, the Japanese came in and taught us about their ways. Companies like Toyota and Honda had developed a process where they would reduce inventory to save cost, time, and space. They called it “Just-In-Time” or “JIT”. What this meant was from now on, plants were only going to keep a limited amount of inventory in the plant. Reducing the amount of inventory you had in the plant created enormous cost efficiencies. Another benefit to JIT plants was that it allowed for change to the vehicles with minimal cost impact. If for some reason a part was being changed, you didn’t have to waste time and money on moving the old inventory out and the new inventory in. Now, you had a much more efficient system that saved time and money.

The origins of the Just In Time practice made it’s way into software development in the 1990s when the Agile Methodology was introduced. It continues to be the gold standard for the way we build software products today.

Software customers are learning that spending a considerable amount of time and money up front to determine the full scope of your product produces the same results as those American automotive plants. Why develop an inventory of product requirements that could sit on the shelf for months or even years? Why introduce the risk of a high probability of them changing or not being used at all?

The agile approach allows customers to focus their time and money on the immediate needs of the business. It gives you the flexibility to change as your market and business needs change. In agile, you are building a product iteratively, so as the features (or parts) get entered into your product backlog (or automotive plant), you build your platform ‘Just-In-Time’ to increase efficiencies and reduce time and cost.

Instead of spending a considerable amount of time documenting your complete product vision, you’ll spend much less time and money so you can focus on coding and building an actual product rather than what it could look like on paper.

The need to change your product will happen. It is inevitable, so embrace it! Having requirements documented for the long term could end up being a waste of time. You could spend months documenting what the product will look like, only to have the market change or your stakeholders tell you they want to go in a different direction. It is important to stay lean as it will allow you to pivot when your business needs to.

Building software if still fairly new compared to other engineering disciplines. It continues to evolve as technology and the market evolves. A development team that understands how important it is to be efficient understands you can actually evolve to a point where you can be, just in time.

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 )

Twitter picture

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

Facebook photo

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

Google+ photo

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

Connecting to %s