Earlier this year, Kauai, the healthy food restaurant, released a new mobile app. I’m a regular user of the Kauai app, because I purchase their subscriptions, a sweet deal where one can get smoothies for 30 days for only R399.
This particular app release was a peculiar one. Normally, a new version of an app is released on the App Store, replacing the older version automatically. Kauai instead created a brand new placement on the App Store, therefore when downloading the new one, both the old and new were installed side-by-side on one’s phone. In addition to that, a warning message appeared whenever opening the old version indicating that it would stop working on a certain date.
That day came. And the app stopped working. I then tried ordering my smoothie of the day on the new app, and it was incredibly buggy. On the first day, I couldn’t select the Kauai nearest to my house. It kept giving a weird error. No smoothie for that day. On the next day, when I decided to pick another store 5km away, the loading indicator between screens took more than 5 seconds every time, and I could never get to the checkout screen. No smoothie again. The next day, I could get to the checkout screen, but it wasn’t loading my subscription correctly. No smoothie again.
One week later, the app had “magically” undergone considerable improvement, and all the previous malfunctions had been fixed, allowing for my smoothie fix. Was Kauai Juice (Pty) Ltd aware of how broken the service was the previous week? How quickly were they able to rectify these issues to regain a good customer experience?
“Agile” has become a stale word in most large organisations, and has come to mean a set of procedures and ceremonies for many. At its core though, agility is the ability to quickly respond to information. This involves two elements – the information, and the response.
In the early days of the “agile” movement, software development teams were encouraged to interact with the end users of their products (gathering the information), and then to release value to the customers in small increments (the response) so that they could get continuous feedback on whether the software was fulfilling the intended need. In addition to this, software development teams were encouraged to put practices in place that ensure that the risk of breaking something with the faster pace of releasing software is mitigated.
When larger organisations started adopting these practices, it became a bit more tricky. There are so many inter-dependent parts of a large enterprise, such as risk committees, legal departments, product teams etc who form part of the process of releasing software. The simple practices of small teams couldn’t easily be adopted, such as development teams having regular communication with the end users. To try and get the same benefit, standardised practices such as Scrum and Kanban were developed and adopted to each context. Larger and more encompassing frameworks such as Scaled Agile Framework (SAFe) attempted to bring formalised processes into the enterprise-wide coordination and orchestration.
As “agile” has become ubiquitous in many organisations, two caricatured camps have developed – on the purist side of the scale are the Monks who feel like the agile of today is not what was intended, and on the other side are the Pastorpreneurs who have created a religious enterprise of the whole thing, complete with rules, procedures, hierarchies and certifications. In the middle of them are ordinary teams trying their best to figure out how to deliver value to customers.
What the warring camps sometimes fail to realise is that the need for agility isn’t universal, and therefore what it looks like in various contexts will be different. Facebook famously boasted about being a company that moves fast and breaks things. Which is perfectly ok for an aggregator of conspiracy theories. If my bank moved fast and allowed for things to break so that they can encourage experimentation, it would be a dereliction of duty. It’s perfectly ok for Spotify to have autonomous, self-reliant teams so that they can release independently to customers. That may not work in other heavy-regulated industries such as insurance.
Yet, despite the differences in context, there are some common features that can be shared across the different environments. Is an organisation gathering enough information on their customers needs? In the Kauai example earlier, when something crashed or failed on my device, were they monitoring that? Does the organisation in question know when things go wrong before the customers know?
Secondly, is the organisation able to respond effectively. Do the software teams have ways of releasing new software quickly while ensuring they aren’t breaking existing functionality? Does the organisation have processes in place to ensure value is released to customers in a short space of time, while protecting the legal, risk and operational integrity of the organisation?
One of the things that sets organisations apart is their ability to adequately respond to customer needs. The goal of agility and all its associated practices is to enable organisations to collect the necessary information, and to respond timeously. Let’s not lose the goal as we figure how to contextually apply the practices.
Patrick Kayongo 