Being agile for the win, again.
We’ve recently been asked to submit a proposal to rewrite a client’s application. The application has been in production for over 10 years and although it is still working, the ageing tech and lack of maintenance have become a blocker for the business.
We were not the first developers to be approached with this task, in fact, two other companies had tried to do the rewrite, but without success. This was a red flag for us, this signalled that the relationship between the client and software developers were anything but ideal. We’d rather not take on a new project than getting into a situation where we cannot deliver or the customer does not deem the project a success. We started off by reviewing the current software and the previous project proposals and spec documents. This step was incredibly important, from this we realised that they have not heard of the Agile software development methodology and had document after document describing the desired functionality, data schemas and test cases, it was clear that they had been on working on this spec for a long time and had put a lot of thought into it. Yet none of the previous developers could make their vision a reality.
We were not interested in a Waterfall project and after explaining the Agile methodology to the client, they were a little sceptical, but willing to give it a try. We liked the client and the industry they are in and decided we’ll put our money where our mouths are and show them the power of this “new way of working” before they commit to the project (and us) contractually. We asked them a simple question
If you had one thing you could add to your existing application, what would it be?
We got a list of things, obviously, but we were able to narrow it down to that one thing. The one that would demonstrate our capabilities and the value of our way of working. Without going into too much detail, the one thing ended up being really simple, they want carers to submit patient observations as they are observed, instead of writing it down and submitting it once a day or sometimes once a week, where an admin staff member would capture it in the system. This would allow them to identify anomalies much quicker and gain insights into how carers are going about their daily tasks. This was a winner and the funny thing about this request was that it was never explicitly mentioned in the spec documents. They simply assumed that if the design spec was met, they would have this capability. Now, that we had something to work towards we started unpacking this one thing.
To userland!
First, we interviewed a few of the system’s end-users and managers to get a feel for their workflow and how they interact with the system. We quickly realized that although technically simple, operationally it might be a challenge to implement. For one, most workers don’t own a smartphone and the few that do own a smartphone is not allowed to use it during office hours.
At this stage, we’ve only spent a few hours on the client and already we were able to identify a real problem that could potentially change how they envisioned their application from being used.
We had two big assumptions we needed to test here:
- Given the carers’ limited exposure to smartphones/computers, would they find recording observations in a mobile app doable, while not distracting them from taking care of patients.
- Facility managers would allow carers to use a phone to capture observations, as well as gaining additional insights from having access to this data in real-time.
Now that we knew what we wanted to get out of the experiment, we had to start building something. We identified a few facilities and a mix of carers (some that had their own phones and some that would use a phone that would be provided by the facility).
We settled on building a simple Telegram chatbot, with the bot code running in AWS Lambda using DynamoDB for storage. This would serve as a simple and familiar interface to carers and be super quick for us to get up and running*. To get the data to the managers we simply did a data extract every morning and evening. We ran the test for a few days until we had sufficient real-world data.
The experiment ended up being extremely valuable and we were able to validate our assumptions and identify additional things to consider when building the production version of the application.
Why do this?!
We love reading stories about how startups adopt agile and lean practices and the benefit they got from it, but you seldomly get the opportunity to properly live it. This exercise challenged us to tackle client engagements in a completely different way, instead of lengthy contracts and rate negotiations, we showed the client the value we bring, before signing any contracts. We also showed the value of getting software in your end-users hands as quickly as possible and having a partner that will challenge you when needed.
We like to think of ourselves as innovative and able to come up with creative solutions, but too often we reserve that part of our brain for clients and continue doing business, contracting, resourcing, recruiting, remuneration, and and and the same old way. We will continue to challenge ourselves, the way we do things, and our clients to ensure we reach our maximum potential.
The client decided to bring us on as their official technology partner to build their new platform, but also help grow their business. We are extremely excited about this opportunity and can’t wait to see what the future holds.
In the next few weeks, I’ll do a writeup on the Telegram bot we built and open source the bulk of the code to help you get started with your next project!
*Given the nature of the data, we had to replace any personally identifiable data with something generic that could be mapped back to a patient outside of the system.
