Home Insights CHESS Moves #1 - Scaled agile in action
Share on:

CHESS Moves #1 - Scaled agile in action


Posted In: Institutional Broking and Clearing, Retail Broking and Institutional Capital Markets
Published: 29/04/2020

Go behind the scenes of our ASX CHESS replacement project with Martin Rady – Program Manager, CHESS Replacement, and Andrew Zietara – Product Owner.


How many GBST products are being upgraded as part of this ASX change?

Andrew: The CHESS Replacement impacts the products that our clients rely on to run their back offices and settle billions of dollars of ASX trading every day. Three of those products require major development to connect to the new Clearing and Settlement Platform (CSP) – Syn~ANG, Shares, and Margin Lending.

We’re also creating a new product to connect our clients to the new system – Syn~MAP which replaces our Clearview product with a new Syn~ solution which is much more modern

What are some of the key challenges of the CHESS replacement program?

Martin: The structure is challenging – the ASX specifications are non-linear. For example part of a feature could be delivered at the start of the project with the remainder delivered towards the end. This has created challenges for us in building ‘shippable software’ as mandated by Agile.

We’re also adapting to changing timelines as we go. The ASX just announced plans to delay the project due to COVID-19 so we will have to adjust our plans, resources and budgets accordingly.

What project approach do you use to balance unpredictable workloads?

Andrew: The CHESS project needed a different take on our traditional development process. Under a scaled Agile approach, our portfolio team digest information from the ASX and key forums – including specifications and potential client impacts — feeding work to the development teams.

We adapt the level of detail in our designs depending on the complexity of each ASX change. To meet tight deadlines, detailed definitions for updates to existing functionality are crucial. This has been especially challenging having to balance the needs of three very different stakeholder groups – ourselves, ASX and our clients.

How many people are working on the CHESS project in GBST?

Martin: Six development teams are part of our multi-million dollar CHESS Replacement program. That’s around 70 people full time in teams across Australia, Ukraine, Vietnam and the UK.

We’ve recruited in Australia and overseas for the right skill sets — although we have one of the largest CHESS-capable development teams in the country, the size of the program meant we had to scale up. Building these teams against a backdrop of changing ASX specifications and conditions has been a balancing act. But we’ve scaled effectively across four time zones to have the right balance of skills to fulfil rapid development needs.

What are your everyday project tools?

Andrew: Jira and Confluence manage the core elements of the project — standard industry tools for Agile development. We also use an add-on to Jira called Portfolio to manage multiple teams and streams of work. Leveraging tools we knew worked for other teams at GBST helped us scale up quickly without having to tinker with the process.

Like the ASX, we’re using Confluence for client communications. Stakeholders can access our portal for an overview of ASX updates, milestones, and specific analysis of GBST product changes and the design decisions we’re making.

What have you learnt from other GBST teams about structuring this scale of project?

Martin: We spent time understanding how other large projects within GBST have operated. Key to how we structured our project was the balance between defined scope and flexibility as the ASX specs are released.

And the importance of leveraging the experience of everyone in the team across roles. For example, we created a forum for our scrum masters to share processes, ideas and issues which has built strong relationships and sparked collaboration across teams.

There’s a lot going on. How do you make it work day-to-day?

Andrew: Rhythms and routines, and agile ceremonies are important. We do daily standups for each of the scrum teams, timed to maximise time zones. We also have governance forums at each level for real-time flows of information.

And we use Jira and Confluence as our corporate knowledge repositories which are easily accessible and constantly updated.

How do you manage teams across 4 different time zones?

Martin: Working across multiple time zones takes flexibility. We’ve adjusted working hours for some Australian-based staff who are working with offshore teams in different time zones.

We’ve trialled combinations of Confluence documentation and videos, and finding the right amount of detail for developers. Our approach has evolved as team knowledge and expertise mature.

What sort of features need to be updated across products?

Andrew: Where functionality is similar or like-for-like, our goal is to make as few changes as possible. Where functionality is new or significantly different, we take a user-centric approach – how does this change impact our client and how they use our product.

How are we ensuring that what we build is fit for purpose?

Andrew: We invested in a four-month Pilot project to explore how we would approach the design and development for the ASX changes. This covered all aspects of the ecosystem, from architecture and connectivity, to how we can adapt our products for various types of changes, from new functionality to changes to existing functionality.

This foundation ensured that we could commence development with a well thought-out architecture.

How will we know the project has been a success?

Martin and Andrew: Success is when our clients go live with no business interruption. We have a great track record of making system transitions and updates seamless for our clients and we will be making sure this continues with the CHESS Replacement.

Get in touch to discuss our CHESS updates

© GBST 2021. All rights reserved. Website Design