TASS has recently changed the way that we develop software, moving from large biannual releases to more frequent, monthly releases instead.
Whilst that looks simple on paper, a lot of research, planning and hard work happened behind the scenes, from all the different TASS teams, to ensure that our development process continued to provide the best possible experience for our customers.
To share more on how this change was decided, implemented, and what it means for TASS users, we spoke to TASS Development Manager Brad Fleming about the project.
As the driving force behind the new development cycle, Brad also had some valuable tips for managing organisation-wide change, getting buy-in from stakeholders, and managing the risks associated with major projects like this.
To understand the why and how of this process, it’s important to know what we changed to and from. So, if you’re not familiar with common software development processes, here’s a bit of background:
Background on TASS development
In the development world there’s many styles of project management, but the two main methodologies are Waterfall, and Agile.
Waterfall takes a very linear approach, having been adapted for software development from its origins in construction and manufacturing. Just as the foundation of a building must be complete before the framing or walls can be built, waterfall development requires all of the planning and design to be completed before development can start, and all development to be complete before testing occurs.
For a long time, Waterfall was the main methodology used by most software companies, including TASS – mainly because it was the only option available. However, Agile has grown into a popular alternative to Waterfall, structured around the requirements of modern software development, rather than translating the process from another industry.
Using Agile, development is broken into smaller parts – so that rather than planning every feature at the beginning, then developing them all and so on, developers can focus on a single feature or part of a project, develop it and get immediate feedback.
TASS has made the switch from Waterfall to Agile, so that our development now happens in shorter two-week iteration cycles, with two iterations per monthly release.
As in the diagram above, at the end of each iteration we have a tested, releasable product that is built on in the next iteration.
Why change the development process?
As with most large changes, there’s not just one single factor that led to TASS making the switch to a new development cycle.
Ultimately, the decision came down to three key points, which Brad broke down as:
Development growth
For several years now, TASS has been steadily growing in both software capability and team size, and as the development team grew, our output increased substantially.
However, with enhancements still coming out in twice a year major releases, there would be a huge influx of new features being delivered to schools all at once – often over 500 items in a single release.
This process firstly meant that a huge amount of testing and BETA release feedback was necessary up-front, potentially delaying general release if anything needed to be addressed or readjusted.
It also meant that customers found it difficult to get up to speed with new versions and become aware of all that was included - due to the sheer volume of new features and changes introduced.
Flexibility
Flexibility is especially important for systems like TASS that are critical to school operations, explained Brad.
In the new agile process, as planning, development and testing all occurs in the same development cycle, there’s flexibility to change priorities or switch to something else entirely at the beginning of the next cycle.
This means that if anything urgent is needed – such as a new government return requirement, it can be addressed quickly without impacting a larger development timeline.
Access to features
Under the previous waterfall model, a feature could be completed early in the cycle but not available to schools until the next major release, sometimes up to 6 months later.
With releases now happening more regularly, schools can have access to features as soon as they’re completed. As an added benefit of the way TASS now develops software, we can also allow the early release of new features to schools that have agreed to test and give feedback on TASS enhancements.
This is done using ‘Feature Flags’, which gives us the ability to toggle bits of code on or off as needed. This allows us to develop larger projects without impacting the ‘live’ TASS system, and more easily test new features and enhancements with TASS schools.
What did the change process involve?
The first steps of the changeover process began over a year ago, with a lot of work required from across various TASS departments to get to the finish line.
However, Brad shared that the biggest challenge of the project was ensuring that everyone was on the same page about what the change would involve and what the benefits would be. As a fundamental part of the business, changing the development cycle would impact all areas, and required agreement from each business leader if the project was to go ahead.
As we’ve talked about before, identifying and addressing any concerns or questions is a crucial step in successful change management, and Brad’s experience was no exception.
He explained that showing people that their concerns are genuinely being considered, and being able to back this up with an explanation of how positives would outweigh any issues, was essential in driving that shift in mindset. This took a lot of discussions, diagrams, and research, but was worth it in the end.
Once everyone was on board, the next challenge was getting everything ready for the new release cycle – which involved getting all development and testing to a ‘zero point’ so that the shift from 6 month to monthly releases could begin.
What was the impact of the change across TASS?
With everyone on board, some major changes had to happen outside of just the development teams.
Internal processes, especially around documentation and support, had to shift to align with the shorter timeframes of the new development cycle.
Under the 6-month waterfall cycle that was previously used, subject matter experts and the customer care team would workshop prior to each major release. This allowed them to get up to speed on all of the new features and changes, so that they are able to support customers post-general release.
With monthly releases, the customer care team have to be more in tune with features earlier in the process, as they’re being developed, ensuring that they’re across every change in each monthly release – and that support, customer communication, and documentation is ready in time for the shorter cycle.
Advice for anyone undergoing a similar change management process:
Whether you’re changing a core process or introducing new software, Brad’s main piece of advice was to always do your research.
Many people can share a horror story of going through a change led by someone who wants to do something new, but doesn’t understand how things are currently done or why. For changes to be well-received and actually stick, it’s important to be able to quantify what will improve or change, what worked or didn’t work with the existing process, and be able to explain this to everyone involved.
“Make sure everyone can get a clear understanding of the changes, and you have the research to prove what kind of positives can happen. Even though it may be painful at the start, it’s worth the effort.”
