A Different Approach – Creating AdaptUX

Did you know that AdaptUX was created using the Agile software development methodology? In his latest blog, Rob Hayesmore, Head of Product Development, AdaptUX, reveals how the change in approach bore exciting results for both developers and users of AdaptUX alike…

An Agile process

We fully embraced the ‘Agile’ development methodology known as ‘Scrum’ and applied it to both the engine (the central ‘core’ of the program) and configuration (tracking and controlling program changes) areas of our software.  All aspects of our newly-released recruitment-specific CRM, AdaptUX, were created this way – alongside the majority of its supporting software such as the Adapt Outlook Add-in (AOA) and the Adapt Desktop Agent (ADA).

Scrum is a huge change in approach from the traditional ‘Waterfall’ process.  With Waterfall, you design, develop, test, fix, final regression test, then release; so the development phase is quite long, around six months typically. It’s also risky because you may find a number of things to fix when you eventually start testing. 

An important part of the Scrum methodology is working in short, two-week cycles called ‘Sprints’, which continuously test alongside the development as features are completed. We also added Continuous Integration (CI) to the process, meaning we run automated tests overnight which test much more of the software than would be possible via manual testing during the same length of time; helping to ensure consistent functionality and improving quality.  

Sprint to the feedback

At the end of each two-week Sprint, we demonstrate new software features to our stakeholders and request feedback; ‘non-techies’ would see them and their comments would direct ongoing development.  Working with regular feedback in this way, new features such as the expandable and collapsible menu view, Calendar and Tasks within AdaptUX often became even better than originally envisaged.  

It’s all about seeing something in reality, not just a concept.  Why show concepts on whiteboards when you can deliver something everyone can actually ‘click’ and see working?

Testing for success

With Scrum, you test as you go in many small iterations. We do two types of testing, Unit Testing and testing within our CI (Continuous Integration) environment.  Unit Testing is at the code level and involves testing individual pieces that have changed. CI Testing tests those pieces working as part of the complete system.  In order to do this, we create and deploy a version of the software, then we manually build the test scripts telling the system what to test and what success and failure is.  The tests automatically run overnight and a report is generated for us to action the next day.

Running both types of test is like building a boat, testing it in a pool, then testing it out on the open sea.  We build part of the hull, improve the design and test that in isolation, then, via our CI environment, we add the superstructure and drop the boat in the water.  Hopefully, the hull still works with everything else around it and it’s seaworthy, or maybe it will be top heavy, capsize or sink – if that’s the case, we know what to fix.  If you don’t test the pieces that way, you might look at your new hull in isolation and think it’s beautiful, it works, it’s stable and doesn’t leak – but in reality, until you put everything together you don’t know for sure.  That’s why testing within the CI environment is so important.      

By working in an Agile way, not only are we more responsive and able to change direction every two weeks, we can also build much higher quality, solid and dependable software.

The methodology works

We believe the success of AdaptUX 1.0 proves the Agile/Scrum methodology works. 

We changed our methodology, developed AdaptUX in a very different way and delivered higher quality software to our clients.