A New Era in Recruitment Software Development
The recruitment industry is evolving more rapidly than ever before and competitive recruiters need the best software to support their working practices – now. Daniel Richardson, Chief Technology Officer, Bond International Software, explains how software providers adopting the right development methodology can react quickly to industry change and ensure recruiters stay ahead.
How were things previously done?
Software companies have traditionally used the ‘Waterfall’ method for software development. Waterfall can have different lifecycles and stages, but the fundamental principles remain: First, functional and technical specification documents are written; then the software is built, tested, and finally delivered to the client. Waterfall has been a very thorough, effective method for building and delivering innovative and reliable software, but it does have some drawbacks. The life-cycle described above takes time and the clients business may have changed during the course of the project and additional or different functionality may be required following delivery. So at best, the delivered software represents the client’s requirements when the project started. At worst, it bears no resemblance to what is required now.
An Agile future
Around three years ago, Bond introduced the ‘Agile’ and ‘Scrum’ approach to developing the Adapt engine and within the last few months, applied it to the bespoke configuration side as well. At its heart, Scrum is an agile method for project management.
So why is Agile so great? Well, taking a look at the Agile Manifesto, we value:
- Individuals and Interactions over processes and tools.
- Working software over comprehensive documentation.
- Customer collaboration over contract negotiation.
- Responding to change over following a plan.
In other words, we don’t get bogged down in laborious plans or documentation, but go through a process of continual product evolution in collaboration with our clients, making small increments and deliveries as we go.
In order to meet the Manifesto described above, we adhere to the following principles:
- Our highest priority is to satisfy the customer through early and continuous delivery.
- We welcome changing requirements, since agile processes harness change for the customer’s advantage.
- We deliver working software to our respective internal and external teams frequently.
- Business people and developers work together daily.
- We build projects around motivated people.
- We strive for simplicity.
- We adopt self-organising teams.
- Our teams regularly reflect on how to become more effective.
Within Scrum, a Product Owner considers all the requirements and creates a number of ‘Stories’ in a backlog. Instead of writing exhaustive specification documents upfront and strictly adhering to them for months (Waterfall-style), the individual stories form the requirement. The team then assess the stories based on the time they will take to build and test, then breaks them down into units (such as 5 units for small jobs or 21 units for large jobs). The Product Owner then sets story priority, ensuring those most beneficial to the customers business are completed first.
The aim is to deliver a working product at the end of every sprint – a huge advantage over the traditional Waterfall method which meant awaiting the end of the whole project to see the software in action. Further sprints deliver new functionality and stakeholders (internal and customers) can see how the product is evolving and make amendment and improvements along the way.
How did Agile and Scrum come about?
Scrum was first implemented by Jeff Sutherland back in 1993 and followed up by Ken Schwaber in a paper he wrote for OOPSLA in 1995.
Legend has it that back in the 90’s Jeff’s software project team were told the budget for their current project was being significantly cut and they would be expected to deliver in about three months, not the originally agreed nine and additional features may be required. After much deliberation, they came up with a new approach. They continued to work on the project, further developing the software in parts but never to the point where the whole system stopped working. This enabled them to deliver the software whenever requested, rather than keeping the client waiting nine months for a ‘final’ product which would then be subject to changes. The team named their new approach Scrum and it began to catch on throughout the industry. You can find more information on the history of Scrum here.
Scrum follows the ‘house analogy’: There’s a storm coming, you don’t know exactly when, but you need to rebuild your house to withstand the onslaught. You could take all the windows out at once but it makes more sense to replace them one at a time, ensuring each is strong before moving onto the next – just in case the storm hits before all the work is finished.
Around three years ago, Scrum really took off and there was a huge groundswell in its parent methodology named ‘Agile’. All kinds of software is now developed using Agile, from Hive (the British Gas thermostat) to Google Nest and Spotify. A number of Scrum-type processes now sit within Agile, but the most popular remains Scrum.
Scrum has become so effective and influential that some software providers claim to use it when in actual fact they’re using what has become known as ‘Scrum But’. Scrum But is when the process is similar to Scrum, but certain work is undertaken differently, such as writing a specification upfront or using larger teams of developers. Scrum But is not Scrum, however the differences are understandable – moving over to Scrum is a real paradigm shift. Developers can wrangle with the methodology (have they lost or gained control?) and it takes time for teams to operate effectively and really see the benefits. Adopting Scrum is the biggest software development change Bond has ever made and it’s proving to be the most beneficial.