One of our key strengths, or USPs if you like, is our ability to develop applications and software products that extend the capability and functionality of our customer’s ERP solutions to meet those “last mile” yet critical requirements. Over the last 15 years, we have developed well over 100 such applications with plenty more in the pipeline. These include mobile applications as well as the creation of our own complementary products such as Trax, Acquire, MTD and ProScope. All have been designed and developed to maximise the value of our customers’ ERP implementations.
Our solutions bridge functionality gaps to provide multiple benefits to our customers, namely, operational efficiency gains, improved data accuracy, process streamlining, wider visibility of information across multiple sources and enhanced system features.
When it comes to actually developing software, there is no one approach that will guarantee success. Various methodologies can be adopted; Waterfall, Agile and Rapid Application Development are amongst the most recognised. At Cooper Software, our approach over the years has largely been determined by the nature of the project and also the team we have available, however we typically follow one of two approaches: Waterfall or Agile. By approaching software development in this way, we feel we have greater flexibility around the best way to deliver our projects. Both approaches offer benefits to our customers and deliver the same outcome – high-quality solutions that stand the test of time.
We are always looking at ways to improve and ensure we stay relevant and at the forefront of our industry. A large part of this continuous improvement mindset has seen us start to “double down” on how we leverage the Agile development methodology. We feel this approach offers even more benefits to not only our customers but also the engineering teams as well as the business as a whole.
The journey towards agile software development
When John Burns joined Cooper Software in January this year as a senior developer and Professional ‘Scrum Master’, he introduced the business to a new way of approaching software development – the Agile methodology, Scrum.
While Scrum itself is nothing new – it’s history dates back to 1986 when Hirotaka Takeuchi and Ikujiro Nonaka first used the term to describe a more efficient way to approach product development and was further refined in the ’90s by Ken Schwaber and Jeff Sutherland when they specifically applied it to software development leading to the development of The Scrum Guide – it’s an approach that until now hasn’t been practiced at Cooper Software.
In this article, John explains the methodology, the reasoning behind Cooper Software’s desire to become ‘Agile’, and how he is facilitating the use of Scrum in his role as Scrum Master to bring benefits to both our development teams and customers.
Agile is an umbrella term that describes a series of software development methodologies that are derived from the concept of carrying out small iterations of work. Under Agile development principles, requirements and solutions evolve through collaboration between self-organised, cross-functioning teams.
Scrum is one of the most widely used agile methodologies and is particularly suited to large scale, complex projects. It is a process framework that organises a development team that have the collective goal of getting more work done in a shorter space of time. It challenges the traditional sequential approach of software development by allowing teams to self-organise and closely collaborate by undertaking short incremental bursts of work, called ‘sprints’ before reconnecting and engaging with the customer to present back, refine and then proceed with further sprints until the product is fully developed. Such is the success of the approach, it has been adopted globally by SMEs and multinationals alike including Spotify, Google, Apple and Microsoft.
Scrum excels where a project is complex in nature or has a lot of unknowns. Scrum puts the accountability back on the customer. Often, at the beginning of a project, the customer doesn’t know exactly what they want, they might have a rough idea but don’t have a fully detailed brief. By working in shorter bursts, we give the customer an opportunity at every stage to question, refine and change according to their requirements. There’s less risk involved as the customer always has the opportunity to initiate change.
The essence of Scrum is collaboration. There’s a small, flexible and adaptive team of people with all hierarchy removed – no roles are allocated, everyone involved is simply a ‘team member’. The team works together as a unit during each sprint towards the previously defined common goal. The premise being that as the team is a single coherent unit, they are able to work better, smarter and faster, saving the customer time and ultimately money.
Scrum has clear differences from the more traditional Waterfall methodology, which has typically been Cooper Software’s standard approach to date. Named as such because it involves a logical series of steps through each stage of the project until completion, likened to the flow of water which finally cascades over the waterfall edge. Under the Waterfall method, a project is fully documented in advance with development carried out according to a plan involving a series of steps, with detailed start and end dates for each stage. Only once each task is complete, reviewed and approved by the client, can the development team progress to the next stage. Under the Waterfall methodology, it is not possible to take a step forward or back without having to start the entire process from the beginning.
John explains, “as the Waterfall model follows a more linear, sequential approach it is best suited to projects that have a fixed scope, short timeframe, or a clear deadline and budget. Typically, when using this approach, the emphasis is on the development team rather than the customer and their needs or requirements. The team will take the initial customer brief and then spend a significant amount of time developing against the set requirements. As the demo stage within this approach comes almost at the end of the process, any changes in the parameters of the project will send the entire project back to the beginning.”
This is the key drawback of the approach, particularly in the case of complex or challenging projects – the amount of risk associated, due to the high chance of re-work being required. What’s more, the customer is largely excluded from the process. Scrum is the very opposite, key project stakeholders are involved throughout the entire process, therefore the likelihood of changes being imposed is significantly reduced.
What is the delivery process under Scrum?
The Scrum framework involves a series of Scrum Events. Firstly, a project is broken down into smaller tasks, which are grouped together to become the Product Backlog. This is a list of everything that is known to be needed in the product, essentially user stories. It is regarded as a constantly evolving piece. The earliest version will include the initially known and clearly understood requirements and these will develop and change throughout the course of the project as it becomes clearer what is required for the end product to be a success.
Small tasks are then taken from the backlog, in the order they need to be completed, and given to teams who work within a set timeframe called a ‘Sprint’. “For Cooper Software, each sprint lasts for two weeks. Within these two weeks, the requirements we think we can deliver are agreed upon, worked on and then presented back in a demo to the customer. The customer then has the opportunity to redefine or change any requirements before we regroup and embark on the next task from the backlog in another 10-day Sprint. So, the process continues until we have worked through the entire product backlog, re-grouping and refining as required based on the feedback from the customer.”
The team also conducts a timed 15 minute ‘Daily Stand Up’ to give progress updates. Each team member takes a turn to discuss how their work is going, any issues they have come up against and what they plan to do next. The Daily Stand Up is an opportunity to keep communication open amongst the team so everyone knows the current status of the project and what everyone’s role is. During these sessions, the team often finds ways to overcome issues through feedback and collective thinking, the so-called ‘lightbulb’ moments.
Each Sprint ends with a Retrospective, where the team comes together to reviews their work, what did and didn’t work well or what could be done differently, with this information used to inform and shape the next Sprint.
Scrum teams don’t have a project manager or leader, instead, they have a Scrum Master. The Scrum Master has an important role to play and a difficult balancing act. Their role is not that of an authoritative figure but more as a facilitator, educating the team on the principles of scrum, keeping them focused but allowing them to make decisions on their own.
“My job as Scrum Master is to try and educate the company as a whole and the Scrum teams to the value of the approach and the benefits to both the organisation and the customer. You are challenging people’s mindset, asking them to deviate from their traditional Waterfall way of working. It takes time and involves a considerable amount of re-education, showing people why it works, the benefits for the customers and also what are they going to get out of it. It’s about showing people that we have a great opportunity to increase communications with each other, helping us to constantly adapt and encouraging teams to constantly question and inspect our work, something we have never done before.”
Benefits of Scrum to customers and development teams
Scrum puts the accountability back on the customer. There’s less risk involved, particularly for large, complex projects as the customer has an opportunity to request changes at any point as we continually engaged with them through regular check-ins. Often at the beginning of a project, the customer doesn’t know exactly what they want. This is especially the case when the project is challenging – how can you define something you don’t understand? It’s usually only by working through their criteria that the shape of the solution becomes clear. By working in short incremental bursts and regularly presenting back, we give the customer an opportunity at every stage to question, refine challenge and shape the project. There’s no waiting until the end when we demo something that has been developed based on very limited criteria only to have the customer say it’s not what they want or isn’t quite right.
Adopting a flexible development approach
As outlined above, choosing which methodology to adopt depends on the individual requirements of each project and the team we have available. Having the ability to adapt to both types of development frameworks enhances our development offering to our customers. For our development teams, we want to make sure they are empowered to work in the way that they see as being the best fit for them and the project. We are keeping up with the latest thinking and trends, ensuring we can respond to alternative ways of working, depending on the project or task, ultimately delivering greater value to our clients.
If you have a development project you’d like to discuss or would like to understand more about how we can work with you to develop a solution for your business, please get in touch.