English | EN 
Did you know that when Amazon first decided to introduce their gift cards, they took just 90 days to roll them out?
Just 90 days to transform a business idea into a product that was available for purchase by consumers. Think about that.
What does it take for an organization to be this agile? More importantly, what are the key principles or practices that we can adopt to make our own companies, businesses and organizations as fast moving as this? The answer is not far to seek- it lies in the concept or philosophy of Continuous Improvement. Now, this is not a new idea. In fact, related concepts such as kaizen have been around since the period after World War 2 and were most famously expressed as ‘The Toyota way’ by the Japanese automobile manufacturing company Toyota in 2001.
Today Continuous Improvement refers to a philosophy where companies focus on making continuous and incremental improvements to their products, services or processes. This requires a basic shift in mindset where companies focus on building a Minimum Viable Product (MVP) rather than a perfect one. Thus, in terms of software development, MVP is a concept that prompts the following question- what is the minimum amount of work a product needs in order to have a new release? This is the exact approach that seems to be followed by companies such as Amazon.
For instance, when delivering the gift card program in 90 days, Amazon obviously did not spend 89 planning it or trying to develop and support many different options. Rather, they would have concentrated on the basics- things like integration with 3rd party providers to load value on the cards, integration with the website and so on. Did they come out with all the options they have available today? No, when they first came out they provided a very limited number of options and the rest of the program developed and evolved over time in response to market conditions and customer feedback. And this is what a Continuous Improvement process is all about, putting out an MVP and then making small increments over time to continuously reach towards perfection.
It would seem that all Amazon products follow this philosophy. If you look at AWS, you will see that more often than not when Amazon creates a new service for AWS, the documentation for the implementers is not fully baked or does not completely describe everything the service does. This is primarily because Amazon is primarily concerned about getting that service out of the door rather than on getting it perfect. The frills are often added later.
The benefits of such an approach ought to be obvious.
The biggest one, is of course, time to market. In a marketplace as competitive as today’s, it is a big one and has several add-on benefits. The sooner an organization gets its product to the market, the sooner it starts seeing revenue from that particular effort. It also starts getting a lot of customer feedback which can put it on the road to improvement much faster than if it were trying to develop a perfect prototype. Under this approach, the MVPs that are not working out are quickly dropped while the others quickly start evolving in response to customer feedback. This helps in eliminating a lot of wastage as one spends a lot less time, effort and resources on options or features which might not work out. When following this approach, you are also not incurring a holding cost of features that sit in a non-production environment
Yet, despite the many clear advantages not too many companies are able to adapt to this approach. I see this with many of my clients, where the architecture teams spend a lot of time figuring everything out, covering all possible potentialities and building a perfect architecture. After all this, a number of SCRUM teams get in on the action and start with the development. This type of approach causes, at the very least, a 3-4 month delay in the development process.
Why is this? In my experience, there are three main factors which are responsible.
The first is that this way of working requires a fundamental change in organizational behavior or culture. Specifically, this requires an agile way of working rather than a waterfall one. The problem, however, is that, while a lot of companies call themselves agile, they only deploy code once every 3-4 months. That is not agile, but a waterfall style of working. I have seen companies which budget millions of dollars for projects involving software applications having a huge set of features. The mistake these companies make is that they first try to plan for and perfect the architecture for each of those hundreds of features, instead of going for an MVP. That is what leads to delays and failures. In short, the companies that get it right fund features while those that get it wrong fund projects.
The second factor that prevents a more widespread adoption of this approach is the lack of trust between business and IT in most companies. Due to this it can often be difficult for the business to ‘buy in’ to the benefits of the MVP approach. This often stems from the historical view of IT departments being seen as cost centers rather than of creating business value by themselves. While the success of companies like Google, Facebook and Amazon have done a lot to demonstrate how software can drive business value, this is a shift in mentality that still needs to take place across different sectors.
The third factor which is quite closely related to the two earlier factors stems from what I call the 8 most dangerous words in the English language i.e. ‘but we have always done it this way’. Often, it is this kind of resistance to change which is at the root of most companies being unable to move to agile modes.
So what does it really take to implement Continuous Improvement in a company?
To take some cues, I’d look at the example of one of our Sogeti clients that have undergone this transformation in its entirety. This transformation, which was led by the CIO, has led to (according to my estimate) a 10-15% increase in velocity across the board. Currently, they have the entire organization working as part of release trains, doing program increments and are doing things like 10-week cycles of 5 program increments or 5 sprints and 5 program increments and so on. In short, there has been a complete change in this company’s philosophy.
Looking at this example, I would say that one of the crucial things that enable such transformations is a change in approach towards architecture and by this I mean not just solution architecture or application architecture but business or process architecture. Adopting this approach wholeheartedly means adopting the concept of emergent architecture, that is to say, we don’t just try to build perfect architecture up-front but work along the lines of a proposed architecture with the understanding that as the product evolves, the architecture too needs to evolve.
It’s important to note that architecture does not refer just to the technical side but also to the business side- so if a company is building a particular product, it needs to think through questions such as how the business should support the product and how it should market or sell it. Organizations need to think through the process architecture that will support these outcomes. Once again, putting in place such processes require not just tools or skills but a complete organizational or cultural change that will enable continuous improvement. And in my experience, the most successful transformations I have seen are those that are led from the top-down or the C-level. It is usually when such initiatives are championed by the C-level that the cultural change required to bring in Continuous Improvement is made.
To summarize, Continuous Improvement is a philosophy that has many clear benefits. Yet, adopting this philosophy requires supporting architecture- both technical as well as business. Creating this architecture requires a change in organizational behavior or culture and this is best achieved when it is championed and pushed from the top-down.
