We just completed our engineering road map for our Android apps at Australia Post. Each year we get together and try to decide on what we are going to do from an engineering perspective for the next 12 months. Each team gets to decide on what should be done now, what they want to complete by the end of the year and whats on the horizon for next year.

The engineering roadmap is influenced by many things such as large product features coming down the pipeline, enterprise changes, third party libraries used in the app and of course Google, Gradle & JetBrains who provide a majority of the tools and libraries that we use for Android development. The engineering roadmap is part strategy, part aspirational, it addresses problem areas, tech debt, spikes for new technologies, architectural changes and provides a plan on how all these things are going to be tackled. During the year we might tweak the road map to include new technologies that are announced at events such as Google IO or Kotlin Conf/Online.

You may be asking whether our team or company should have an engineering roadmap for each asset/platform? The answer really depends on your company’s culture, maturity, ways of working and how your company approaches product development. If your product owners only care about pushing out new features and you never get to work on tech debt then the answer is probably NO. Hint: change jobs and find another company that values the craft of software engineering & product development.

The engineering roadmap should be something that is actionable, you might not get everything done on your roadmap but you should be able to bite off quite a few large chunks. At Australia Post we follow the 60-20-20 rule on our train to make sure our engineering roadmaps are implemented. What’s that you are asking? The 60-20-20 rule is where;

60% of our team’s capacity is used implement features prioritised by our product owner that meet the organisation’s objectives. The features are prioritised using WSJF — weighted shorted job first and scheduled over three months.

20% of our team’s capacity is used for small optimisations such as customer feedback, features that didn’t make MVP or whatever the team feels would bring the most value to the app and our customers.

20 % of our team’s capacity is used to address engineering items outlined in our engineering roadmap and these tech features are prioritised by the Engineering Lead.

We usually refer to these as our feature, optimisations & engineering streams. If we have urgent engineering items that are larger than our engineering stream, extra capacity can always be taken from our feature stream. The only caveat is that all features in the feature stream are assessed on business value, criticality, risk, etc for prioritisation.

Each year our engineering roadmap is presented by our Engineering leads to the Engineers, Platform Manager, Engineering Manager, Chief Engineer, and our Solution Architects. In the presentation we usually include accomplishments & highlights from the previous year, goals for this year, future technologies, key deadlines, key product features, an engineering theme, high level plan, detailed plan and synergies between our apps. Here are some of our slides from our 30 deck presentation.

We usually start with looking back and celebrating our achievements for the previous year.

In 2020 we had a record number of 139K unique users visiting the app , with 417K visits in a single day.

We do this for each of our apps.

The Digital iD app, in conjunction with Deakin University & Mastercard, successfully piloted their new identify verification platform.

We then look at several key technologies coming in the future that promise to have a big impact on improving development.

Like I mentioned before Enterprise changes and decisions can also have a large impact. This year our company is moving off Bamboo and using GitLab for all our CI/CD pipelines.

During the year there are also quite a few key deadlines imposed by Google & other software organisations

It’s always prudent to be at least one or two months ahead of these deadlines. You don’t want to be in the situation where a production bug requires you update a library that is no longer supported but to move to that new version requires one or two weeks work.

This is optional but each year we like providing an engineering theme to highlight key areas of work. Last year’s theme was reuse which reflected that work done to modularise our app to improve build speed, reduce merge conflicts and provide reusable modules. This year we are hoping to simplify our code base and prepare for Jetpack Compose.

We also provide a high level plan on the focus areas for the year for each app.

And then we drill down and provide more details of the actual work that needs to take place.

I hope this gives you some idea what an engineering roadmap is , what it should include and the value it can bring. Each year when we look back at the amount of tech feature that we have completed the year before I am astonished at what we were able to pull off and how much better we are placed for doing this work. Software maintenance is a vital part of software engineering — just like a car if you don’t service it routinely and replace the broken parts then one day it’s not going to start. Software is no different.

Thanks to karl.