Assembly Line Software Product Development

Compared to many of its engineering counter-parts like Manufacturing or Civil/Construction Engineering, Software Engineering, IMHO, probably still has not come to the level where one can see the maturity of standardization across. There are lots of arguments for this and many of them quite valid. Many consider that in Manufacturing (and similar engineering fields), it is all about creating the same thing again and again. Whereas Software is about creating something unique every time. Also, purists do differentiate between Development and Production. Few authors have said that Development is like creating a recipe, whereas Production is like following that recipe. So the variability in both Development and Production should be expected.

I am not going to disagree much with many of the arguments listed above. With more than 20 products I have been actively involved in my career, I know that each one of them had its unique DNA. Each had a big element of variability and trial-and-error model of software development. So I will agree that the expectation of standardization across them would have been far-fetched. However, my talking point in this post is that while at an Application or Product level – things can be difficult to standardize, however at a software delivery level things can certainly be standardized. For me in this post, software delivery signifies what Assembly Line signifies in a Manufacturing scenario – an arrangement of workers, fixtures, processes, and equipment in which the product being assembled passes consecutively from operation to operation until completed.

As part of Version 1.0 program, my team and me took many of the concepts of the manufacturing assembly line at an abstract level and configured them to apply that in our Software Delivery to a significant success. While we were building multiple products each with a complete different and distinct DNAs – we were also keen in making sure that these products go through certain arrangements which were common across all the products. (The possibility of developing multiple products in a Services organization certainly gave us this flexibility to experiment with such concepts; however I think many of these concepts can even be applied in product organizations where multiple product lines/releases do take place)

Here are some of the concepts which we believe resemble the practices of assembly-line software engineering -

  • Standardized Process for a Release – We felt that regardless of the type of product under development – we could standardize the process of how we go ahead in terms of making a product release across all the products. Here are some of the concepts which tried religiously following all across –
    • Use of Iterative way of Product Development Methodology. We even went to the extent of standardizing each of the iteration length to one month across all products.
    • Atleast one dedicated Design iteration would always prelude the Engineering Iterations.
    • Each iteration had fixed set of activities associated with design, development, and tests
    • Typical Releases across all the products were equivalent to 3-4 iterations.
  • Standardized Milestones across the Release – Every product went through similar milestones – Requirements Prioritization and Iteration Plan Development; Retrospection; Deployments, etc.
  • Standardized Product Engineering Fixtures and Tools – While the core product development platform varied from product to product, we made sure that the core underlying engineering platform which facilitated product engineering processes like Requirements Management, Project Management, Continuous Integration, etc.  were as similar as it could get.
  • Standardized Team Structures and Roles – While team size varied based the product complexity – we made sure that the team was organized into two groups – the functional group and the engineering group. Each group had some roles (such as Product Manager, Architects, Program Manager, Engineering Leads, etc.) which were common across all the products. The roles were well-defined so that each individual knew what was expected from them at each stage of the product life cycle.
  • Standardized Measurements and Continuous Improvement Mechanisms –  Each of the products across their life cycle were getting measured by common metrics on the dimensions of quality, schedule, and customer delight. We also made sure that the process across all the products had Continuous Improvement loops built in through methods like Retrospection, etc.

I think Software Engineering with the knowledge of millions of software products delivered to the market across decades can be standardized to significant extent similar to its other counter parts. Once again, I am not saying that recipes can be standardized. However, my argument here is that the process of creating that recipe and delivering that to its end users can certainly be standardized to a great extent.

Thoughts and comments are most welcome.

About these ads

Tags: , ,

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


Follow

Get every new post delivered to your Inbox.

%d bloggers like this: