Beating Expectations With Customer Driven Development

Senior Software Developer, John Plaxton, explains how agile methodologies and scrum processes – combined with the implementation of Gitlab and Kubernetes – helped his team rapidly develop and deploy a business-critical application for a global investment bank in just four weeks.

What could you do in four weeks that would prove to your client just how much value you add to their business?

This was the challenge a small team of Apexon developers faced when they joined a new project and business at a global investment bank. The business had identified a way to increase efficiencies with existing tools that the bank used and believed this would help it save millions of dollars in wasted effort. To achieve these savings, the business needed to get a new software application off the ground quickly and demonstrate sustained user growth and value so that it could prove its business case, or be cancelled.

Not all senior managers agreed that a new software application was needed. Some felt that existing off-the-shelf software would deliver the same functionality with minimal effort. The initial phase of the project was to build a minimum viable product (MVP), a prototype, that would demonstrate the core functionality of useful features and unlock the efficiencies that would make the users’ lives easier. The new software application needed to be built quickly and to provide immediate and measurable value to its users. It also needed to show that it could not be easily replaced by existing software.

The great change management guru, John Kotter, suggested that in driving through changes, it is important to establish a sense of urgency and to target early wins. Setting an initial time frame of just four weeks to build the first version of the application created that sense of urgency, but we also needed to build something useful that couldn’t be done already. Working with the business leaders, we identified that if the software application could pick out experts sitting among the many bank colleagues on a user’s floor, then the user could wander over and ask that person for help with their problem. This was something that previously couldn’t be done, but could easily be determined from the data that the project had access to. It would be a quick-win if we built it into the first version.

The short time frame also helped focus our efforts on only building features that could be realistically delivered in four weeks. Most of the initial development focused on building the web-based user interface and supporting back-end services. The first version of the data storage layer was purely in-memory and only later were we able to replace it with a proper relational database. However, this strategy meant that at the end of four weeks we had a working first version of the application that we could demonstrate to users and senior management. This also meant that the project would be funded for a little while longer.

To find out what new features would be of most value to introduce next, we started user demos and research sessions with the new application. Although it was fairly easy for users to start working with the application, we wanted to uncover what business challenge they were actually trying to solve with it. If we could understand what the problem was and the kinds of questions they were asking themselves, then we could improve the application to make it easier to get relevant answers.

Supposedly, Henry Ford of the Ford Motor Company once said: “if I had asked people what they wanted, they would have said faster horses.” This means that we need to ask more questions to understand the bigger picture of the problems that people are trying to solve. Often users will suggest a solution that they think is appropriate, rather than actually explaining the initial problem and why they propose that solution. Perhaps an alternative would be better. 

As consultants, we can make use of the “Four Whys” when discussing requirements with users. That means to ask “why” at least four times in response to a user’s answer, so that we delve deeper into the underlying problem that they are trying to solve. The better we understand the problem, the better we can tailor the solution to solving that problem.

Over time, these user demos and research sessions turned into opportunities to get feedback on newly delivered features. Often a user would make a suggestion and a week later we would release the change into the production system and give them a nice surprise that we had listened to them and followed through with. They would also be surprised at how quickly we had delivered the new feature too. This in turn generated excitement among the users who felt that they were contributing to the project’s success as well as being able to use the application in their day to day work. They were often more than happy to introduce their colleagues to it as well.

As the number of active users grew, it was no longer possible to speak to everyone personally, so we also captured usage analytics to see which features were being used. Measuring user activity in this way meant that we could focus on improving the features that the users considered were important and discard other features that were not being used. 

Both user demos and capturing analytics were important when debating with senior management about which features should be prioritised over others. Whilst many managers had good ideas and suggestions, they were not always so relevant for actual users working with the application. The feedback from user demos and analytics helped decide what features were important to deliver to the users.

As a small development team, we made use of Agile methodologies and the Scrum framework. This meant that we planned and worked to two-week sprints. Although frameworks such as Scrum are very useful, what they really provide is a structure for different types of conversation between different groups of people. For example, conversations between developers, or conversations between developers and managers, or with users. It is these different types of communication and the flow of ideas between people with diverse perspectives on a project that is the real secret behind the success of Agile methodologies. It is possible to change how projects are managed, but if the change reduces the communication or flow of ideas, then the project will suffer as a result. Knowing this, we ensured that we kept the communication flowing between different stakeholders in the project. Collecting user feedback is just one example of this.

Another important aspect of rapid application development and Agile development is making use of continuous deployment. We were able to use Gitlab as a source control repository and run automatic builds and testing. If the builds succeeded and the tests passed, then the application would be automatically deployed to a Kubernetes environment. Once setup, this pipeline made it very easy to deploy changes to the application in production and keep delivering value to the users. Such tools are also providing communication and feedback to the developer albeit through automated testing. It is important that failures occur as early as possible in the development process so that fixes can be made sooner. Fixing something on a developer’s computer is much easier than fixing something that already made it into production.

Combining these different techniques together has helped us grow the application and number of users. We have generated excitement about the business and the application. We have been able to prove the original business case and even help users working to fix urgent production issues in other systems. The application not only provided much needed functionality for the users, but it was built far faster than similar projects started at the same time. It has consistently beat key objectives and results set for it including demonstrating sustained user growth and adoption. Furthermore, within 6 months of development starting, it has gained senior management backing and is not in danger of being replaced by other solutions.

Now, if you were given four weeks to build something, what would you do?

Good luck!

Appendix

The diagram below, shows the rate of growth of the number of users of the application over four months since the application was released into production.

The web-based application was built with a React UI talking to java micro-services and a PostgreSQL database. The continuous deployment process used Gitlab which deployed to a Kubernetes environment.