Back in 2006 I accidentally formed a theory around the software, and software-dependant, industry; namely that there is a widespread disease plaguing the industry, hurting profits and brands. The disease is that for whatever reason, software always seems to be … troublesome … it tends to be late and have errors in it.
Think about how many times you have experienced problems with your work PC, home PC, phone, car, etc. etc. and as the use and dependence on software becomes more and more pervasive, we encounter these problems all the bit, but we have become accustomed to them and have learnt to live with them.
Now think about how many hours are wasted in productivity, and how many companies have failed because their software caused their products to ship late or degraded the consumers experience with resulting damage to sales revenue and brands. Think of the enormous sums of money we are talking about here?
The ‘disease’ as I originally formulated it was really based in the ability of software departments shipping quality products on time, which in turn reflects the ineptness of software managers to harness what is really an R&D process into a production and manufacturing environment… And once you think about that it dawns on you; "harness an R&D process into a manufacturing environment". This is actually difficult isn’t it? Fundamentally, the R&D process has to find new and innovative ways of solving new problems all the time, and once the design is done, the product is also done. In contrast, manufacturing has much more decoupled design and production processes where one comes before the other as opposed to be an inherently iterative process of gradual elaboration and ever-changing product.
I have been so lucky in my career to have had plenty of exposure to these problems, and witnessed first-hand the monumental impact this has had on a former top brand and industry player. I have also had the luck of being able to refine my thinking and ideas around the topic over the years, repeatedly applying and improving methods to govern software organisations in order to deliver what the customer wants, when he wants it, at high quality.
The basic principle of Software Governance in scaled up organisations (50+) is formulated around the idea that in order to govern an R&D process in a manufacturing environment, you need to apply elements from both.
Many books have been written on the topic of Agile Software Development - basically applying a fundamental research process to software development. Conversely, large books have been written on applying Lean and Six Sigma to software development - process frameworks that are inherently manufacturing based. At the same time you have competing project management methodologies in e.g. Waterfall and the iterative MSF.
None of the above succeed in grasping the problem in its entirety, and crucially most leave out practical advice on the ongoing governance of the software production. Even the renowned CMMi framework does not cover the entire space, and common to all is that they leave out the human factor. Agile does to some extent rely on the quality of the engineer, but the reality is that in a scaled up organisation, the administration and leadership skills of leaders is equally important. Hence, this is my conclusion; In order to create a repeatedly successful software product, the following conditions must be met:
- Clear product vision
- A governance framework
- Active leadership
- Engineering talent
If either one is missing, the production will be flawed and both profit and brand will be suboptimal.
In the very near future I will publish a white paper outlining my experiences and methods. I am looking forward to any comments.
