X
Business

How failed Tcard project brought new life to apps development at Transport for NSW

The Tcard may have ended up being an epic fail, but the doomed project inadvertently changed the way Transport for NSW's application-development team worked for the better.
Written by Spandas Lui, Contributor

There was a time before the turn of the millennium when the buzz surrounding the Sydney Tcard was deafening, and we needed to brace for the upcoming revolution of the city's public transport fare-collection system.

It wasn't long before the project died a fiery death, thanks to a string of delays and a long-running lawsuit, but Transport for NSW managed to extract some positives out of the tragedy, using it as an impetus for overhauling how it approaches software development.

Speaking at the Glintech Business Transformation with Software event in Sydney, Transport for NSW applications development manager Michael Rembach spoke about how his department has changed in recent years, thanks to a project in 2009 that actually came out of the failed Tcard initiative.

A major deliverable of the Tcard project was a piece of software infrastructure that was going to be used not only for the Tcard electronic ticketing system, but also to facilitate a number of other transport-related schemes, including the 131 500 trip planner and the RTA's PTIPS bus priority traffic system.

"While it was OK to cancel the Tcard project, the organisation realised they still needed this piece of infrastructure, so they came to my department, which was a very small IT shop at that stage, and asked us to build it," Rembach said.

The applications teams had always used a sequential design process, called the waterfall model, to build their products. A year into the project, the team was drowning in requests to satisfy a plethora of business requirements, which crippled its output.

"We literally couldn't get a piece of code out there — we couldn't deliver to save our lives," Rembach said.

That was when he decided to give agile software development a go. The agile approach involves breaking down silos in a business, so that everybody is across all development projects, rapidly cutting code and deploying, and making iterative changes to the product.

Rembach specifically adopted the Scrum agile development method that focuses on enforcing project-management rules for creating software, and getting business decision makers to be more involved with the software project.

He hired a scrum master to be the enforcer of this methodology, and pushed his team down the agile software-development road. It worked wonders for the organisation, according to Rembach; what was originally a project running 12 months behind schedule was delivered six months early.

The resulting software was barely functional, but was released to solve a specific problem at the time, with the aim to incrementally improve it through a continuous delivery pipeline.

"The project changed from being Tcard centric, so around fare calculation based on distance to RTA PTIPS project to making sure the buses run on time — it was able to manage with a completely different set of priorities," Rembach said. "Not only was the application successfully completed, but business and IT started working together on set to share goals and visions to actually make it happen.

"Risks and roadblocks were dealt with in unison, and the advantage of fast delivery, and, more importantly, not doing unnecessary work, became clear."

Previously, business managers would tell developers what they wanted to be made, without the developers actually understanding the need for the product itself, which created confusion and long delays where the product had to be checked and signed off.

"The business side had some strategic objectives, but didn't see IT as a partner — IT was just there to get the job done," Rembach said. "It's very important to have IT seen as a business partner."

To do that, his team turned all the functional requirements behind software development into user stories, essentially "dumbing it down" for business personnel to understand.

The department also implemented automated applications testing, something that Rembach highly recommends to order organisations and save time.

The adoption of the scrum methodology was deemed a success, and everybody in Transport for NSW's IT department was subsequently made to be scrum certified as a way to spread the word about the methodology through the organisation.

"IT needs advocates in the business that breeds success," Rembach said. "Agility is not an IT benefit; in fact, it's much harder to build software using agile than with waterfall, because it actually takes a lot of discipline to be self-organised.

"It's not just testing a piece of code; it's aligning yourself in what you want to build."

Since 2009, the applications-development team has developed eight critical applications on time and on budget.

While there are many who sing the praises of the agile method, it will only go so far in the enterprise, according to a survey by Serena Software conducted earlier this year. The survey showed that even with agile processes in place, IT is still falling short in giving end users what they want.

Editorial standards