Our 4 secrets of successful software delivery

A Business Grants Portal Retrospective (Part 2)

When people think of software delivery for government digital services, what usually comes to mind is a traditional Waterfall project, mired in bureaucracy, changing scopes and delayed launch dates. When the project is finally unveiled after 3 years, it often doesn’t quite deliver great user experience for citizens or meet the requirements of internal users. Sometimes, it doesn’t even work very well.

With Business Grants Portal, we were able to deliver in less time and with a smaller budget than was initially estimated (based on previous government digital projects of similar scope because we used a different approach.

To be honest, these 4 ‘secrets’ might not be secrets if you work in a modern technology company. What most people find surprising, is that a team delivering digital services for the government works this way too. We hope our secrets inspire more government agencies to change the way they deliver software.

Secret #1: Agile development

Business Grants Portal was one of the first whole-of-government digital services developed using Agile. This allowed us to deliver features with high business value first and deprioritise features with low business value, so that we could deliver greater value for every dollar.

How Agile development delivers value sooner

We launched our first grant in 12 months and the next 5 grants over the next 6 months — a much shorter time to market than traditional Waterfall development, which typically takes at least 3 years.

Continuous Integration and automated testing

In Agile, all code is fully integrated and tested at all times. Whenever there are new features, all the existing and new tests are run automatically and have to be passed before the new feature is merged. If the regression test fails, the development team is notified and the issue will be fixed immediately, preventing any bug from growing into a fatal error.

Check out our automated testing tool, hats

Traditionally, testing is done manually and as the product grows, more manual testers are needed, increasing cost and reducing productivity. All our testing is automated, so as our product grows, only new servers are needed.

With Continuous Integration and automated testing, code quality is higher and deployment is fast, easy and predictable. After our January launch, there were less than 20 minor issues that were easily sorted out.

Faster time to market

Since we slice features vertically in Agile, we deliver one form at a time, instead of a single feature across all forms. This means, we can deliver business value faster — 1 working form in 12 months vs no working forms until they are all ready after 3 years. The earlier a form is released, the earlier we can collect useful feedback from companies to improve the user experience of our portal.

Adapting to change

Release Planning for 2014 and 2015

Change is the only constant in product development.

Over the course of Phase 1, the team adapted to changes in grant policy, business needs and economic conditions.

We even had to change our release plan because one agency couldn’t find a vendor to manage the integration between our portal and their system in time for the release.

Agile allows us to embrace change as we’re not working on a fixed scope. Instead we can easily reprioritise and pivot to deliver what makes sense for the current situation.

Co-locating with our product owners

Our Agile development would not have worked so successfully if we didn’t have great product owners from the Grant Management Office, Ministry Of Trade And Industry, who were open to being co-located at Hive.

With the development team and the product owners working in the same place, communication is open, honest and immediate. Both sides can simply walk over and have a quick chat to clarify issues or update each other. This way of working has led to a strong relationship built on trust and understanding that empowers the team to deal with change quickly and efficiently.

Secret #2: Iterative user experience design

We’ve conducted extensive usability testing on Business Grants Portal and something we hear quite often is, “This looks nothing like a government site.” We’re taking that as a compliment ;)

After testing our first grant form, we rearranged some of the components so the flow made more sense to users, made some of the labels clearer and added in alert messages at critical points.

As our form components are reused for other grants, our design continues to get tested and improved on as we build. Our current forms are continually improved and new forms that we add benefit from the cumulative learning.

Our stakeholders at each grant administering agency have been awesome at convincing companies to take part in our testing, giving us a pool of real users to test with and build a great product.

Secret #3: Strong teams

Building a product is important. Building a team is equally — if not more — important.

Grow cross-functional capabilities

Pair programming, where team members with different skills work together on a single feature, is an important part of how we develop Business Grants Portal. This gives the team opportunities to learn from each other and grow the breadth of their skills, resulting in individuals who are cross-functional.

By growing cross-functional capabilities, our team grew from a single squad of 7 to 37 across 4 squads, with each squad having the capability to deliver its own end-to-end working product increment.

With transparency comes trust

Our Scrum board is the single source of truth for all the features to be developed in the Sprint

The foundation of a high performing team is trust. To build trust, there must be a high level of transparency. We use information radiators so everyone in the team can see the latest development information at a glance. This promotes transparency, a common understanding among the team and responsibility.

Our Definition of Done (DoD), which sets the expectations for ‘Done’ features, is updated collectively by the team during Sprint Retro

Secret #4: Co-sourcing

Working as a team with our vendor, Cognizant

Most government digital projects are fully outsourced, with in-house project managers engaging and managing a vendor. At Government Digital Services, we have moved to a co-source model, where our in-house product development team works with a vendor.

This facilitates the flow of knowledge and expertise between the private and public sectors. It also allows us to build products that can be reused and shared across government agencies, as well as design our systems so that they don’t need to be overhauled every few years.

We hope to inspire more agencies to move from project-thinking to having a product mindset.

While we’ve made a great start on Business Grants Portal, we’re excited about what else we can do to make it better. As always, we will continue to gather feedback and improve what we’ve already built.

If you have any ideas on how we can improve our current grant administration, leave a comment or drop us a line.

If you enjoyed this, find out more about our Business Grants Portal journey in Part 1 of our Retrospective.