Shifting to Progressive Elaboration and choosing Rally

Managing an efficient backlog and allowing engineers to focus is the most critical part of modern agile delivery. To support these outcomes NAB has shifted development to a standard way of working called Progressive Elaboration with Rolling Wave.

What does this mean?

In short, we’ve streamlined and made all aspects of delivery visible across our company. This is also helping NAB support some structural changes and new ways of working aligned to a ‘Domain’ based model focusing on delivering improved efficiency. It also better aligns to a Domain based Architecture — which will be a topic for a future post — but for now refer to the Domain Driven Design for Services Architecture if you want to know more.

The Domain model is helping NAB create an efficient way of working that is grounded in tech alignment to the business. This sees a technology group not only structured to support the business but also become integrated into a Domain aligned to a customer need (e.g. Home Ownership). Domain Owners give clear guidance on demand and the creation of business aligned Product Owners (who prioritise work for the technology squads that work with day-to-day) are the key enablers for improving squad efficiency and success.

But when Product Owners are aligned with two or three squads this can present an interesting conundrum. Working directly with squads means that they have to prioritise the work associated with those squads — a day-to-day function that is critical to supporting how NAB delivers. Release Train Engineers (RTE’s) orchestrate the delivery of work, lining up the inter and intra Domain dependencies that are required to enable a technology solution end-to-end.

The purpose of the new enablement model is tri-fold:

1) To integrate the business leadership teams;

2) Create clear transparency of all work across the ~8,000 (including partner organisations) engineers and associated businesses teams; and;

3) To ensure there is predictability in delivery for the over 750 squads that facilitate the engineering delivery ‘conundrum’.

So if delivery is a conundrum, what exactly does that mean?

NAB has traditionally looked to people to support analysing and understanding where work is in the delivery process. This means that the priority of work can sometimes be haphazard — with some work often started as soon as possible which pulls engineers away from existing delivery. The new model means that the work is aligned to when the work can actually be delivered — driving both predictability and greater efficiency than the models we’ve used in the past.

What is the new delivery model?

The model is centred around enabling engineering teams and doing so much earlier in the process. Why? Because our experience is that by enabling the engineering squads to understand and articulate how a solution can be delivered, we obtain a much more accurate definition of a true solution. We also understand much earlier if we should qualify out the ability to deliver a solution. There is significant opportunity to qualify work out earlier, prior to significant investment, following the “fail fast” approach. Stopping work is efficient, we should never keep working on a technical enablement piece just because we think it is a good idea, when the data is showing us otherwise.

What are the initial findings?

As we have brought the initial teams into the new model, the early findings have been phenomenal. Challenging delivery circumstances have been resolved, inefficient work has been stopped and teams are more focused on business outcomes with clearer value. This last part seems obvious but it’s been the most important finding. Teams (through no fault of their own) want to be busy and pick up the next piece of work in the queue and start. What if they asked ‘should we actually start?’ It’s a shift in mindset — taking a step back (as a team) and thinking “we should only pick up and start this work if we can realise business value really quickly”.

We need to be aware enough to understand if there is any team in the chain that cannot support the team. Imagine a feature delivered to production that no one can use? It might be satisfying for the team to technically enable it — but if it’s not something a NAB customer can use it’s simply a waste of time.

Of course we’re not there yet — we’ve still got a way to go and in particular this includes maturing our Product Ownership Model.

Creating Transparency in Delivery with Rally

Transparency in delivery means that we can align the work that we want to do next, the business is helping ensure that the dependencies happen in the time frame we want, resulting in the predictability we expect. Making change is hard, and aligning people to a standardised way of working can sometimes be against their nature. But it’s critical to running delivery in a functional and efficient way.

This may sound like hyperbole but transparency is the key to supporting a high performing business — and how to effectively work with the most senior people in the organisation.

We tried a number of tools in the pursuit of transparency, but our experience showed us that most were better suited for small teams and not always best for cross-functional and scaled agile management. Rally had a standard data model that allowed us to quickly onboard teams and have them see the delivery easily and in a transparent and predictable way. No other tool on the market was able to meet this requirement, and provide clear delivery elements in real time and at multiple levels. Imagine as an executive being able to find out the status of any piece of delivery through a single dashboard in real-time?

Finally!

Marc Andreessen famously said that ‘software was eating the world’ — and ten years later it still holds true. The health and success of banks (along with most organisations today) is directly linked to their ability to ship new and critical features to customers — and at NAB we’re fortunate have the technical skills, resources and platforms to continuously deliver. Our new ways of working are creating the predictability and transparency in our business to ensure that we create the best customer and colleague experience — along with being a company where the best engineers want to come and work.

If you are curious as to why a high performing engineering team is important for your business check out “Accelerate: The Science of Lean Software and Devops: Building and Scaling High Performing Technology Organizations: Forsgren Phd, Nicole, Humble, Jez, Kim, Gene: Amazon.com.au: Books”

About the author: Andrew Brydon is a Digital Transformation leader with over 20 years of technology experience, creating and implementing strategies for large enterprise organisations. In his role as the Chief Engineer at NAB, he leads the creation of the standardised development platforms and enables transformation of the developer engineering function. This involves using engineering excellence to ensure customers and colleagues are the highest priority in everything NAB does.