The telegraph took about 100 years to reach one billion users. SMS took about 20 years to achieve the same number. WhatsApp took just about 2 years to get to one billion users.
In 1958, the average years a company stayed in the Standard and Poor’s 500 list was 61 years. In 1980, it was down to 25 years, and by 2004, it was 18 years. Now, a company enters or exits the list every 2 weeks. 75% will be replaced within 15 years1.
The world’s economy is characterized by rapid and unpredictable change. In this fast changing world, it has become extremely difficult for product owners to foresee and predict what needs to be built. This uncertainty and change is both a curse and a boon. Any organization that can adapt quickly to leverage a new evolving ecosystem will gain from such volatile behavior, as opposed to an organization that is unable to react to the changes and keep up with the times. As Theodore Roosevelt said, “In any moment of decision, the best thing you can do is the right thing and the next best thing is the wrong thing. The worst thing you can do is nothing.”
The need of the hour: To move from a Factory to a Laboratory
In the past decade, IT projects have worked in a factory mode, where products were designed and built using an assembly-line-like structure where once the product was considered complete, it was released into production. Changes to such applications were then termed as regular maintenance and kept to a minimum.
However, with increasing market flux, that had to change. The only way to really tell how your product meets market demands is to build the product, release it to the consumers, and react to the feedback that they provide. And Agile stepped in with practices such as continuous delivery, iterative development, automated testing, customer collaboration, etc., to give product owners that responsive edge.
While working on a project for a startup out of Singapore, we were faced with an interesting problem. We wanted to build a mobile application for the Indonesian market, but we were unsure about the usage patterns of this application. We conducted the usual workshops to identify the features and we then put analytics in place to indicate the usefulness of a feature. We built a system that could push out new ideas and code into production at the click of a button. We put in mechanisms to do A-B testing and measure the effectiveness of our feature set. Given our limited knowledge of the market, this was the fastest way to reach our stable feature set.
With the age of turbulence upon us, every enterprise large or small will probably have to move from using their IT departments as Factories to churn out software to Laboratories where novel ideas and concepts are developed, tested and produced at a fast pace.
This would require Agility to go beyond IT departments and businesses to be open to change and failure. This calls for Business Agility.
From Project Agility to Business Agility
Project Agility: Scrum and XP engineering practices
Enterprise Agility: Project Agility + DevOps and continuous Delivery
Business Agility: Project Agility + Enterprise Agility + Working closely with IT to design and execute experiments. Change business direction based on new knowledge.
To summarize, while Project Agility and Enterprise Agility are necessary conditions, it is Business agility that will prove paramount to thrive and adapt in the turbulent future.
Project Agility
Enterprise Agility
Businsess Agility
Ability to change your mind on features.
✓
✓
✓
Ability to change software quickly.
✓
✓
✓
Ability to verify if the changes have not introduced any regression risks.
✓
✓
✓
Ability to measure and react to the feedback from the end consumer of the software.
✗
✓
✓
Ability to incrementally envision, build, measure and change direction of the product without long approval processes from the management.
✗
✗
✓
Many thanks to Nagarjun Kandukuru, VP of Strategy at Thoughtworks for his insights.
References
1 “Creative Destruction Whips through Corporate America” Richard Foster, Innosight Executive Briefing, Winter 2012
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.