LeSS Adoption at Business Grants Portal

Published on December 9, 2024

A case study on how the BGP squads became better at learning and responding to changes.

What is the Business Grants Portal?

The Business Grants Portal (BGP) was introduced in 2017 by the Ministry Of Finance, Ministry Of Trade And Industry, and Government Technology Agency. Since its early days, it played a pivotal role in helping businesses in Singapore apply for grants, to support them in market expansion, innovation or productivity needs.

With the ever-evolving business landscape and fast-paced changes in the market, the BGP product team needed to respond to policy changes and iterate the product quickly to support the administration of grant policies.

Read further to find out how our teams learned better through LeSS adoption, and build a better product (with lesser bugs) and achieve time and cost savings.

Our Team’s Initial Setup

Back in 2022, we had 3 squads of cross-functional developers (~6–9pax) and we were practising Scrum since work started in 2015. For our scaled agile framework, there wasn’t one in particular but it resembled closely to Multiple Scrum Teams, characterised by the following:

  • Multiple Backlogs (with different focus: Grant Automation, Grant Processing, Grant Builder), managed by proxy Product Owners, led by a Lead Product Owner.
  • Each squads running their own Scrum events independently
In a multiple scrum team setup, each squad runs Sprint events independently, specialising in their own area of work defined by in their own subset of a product backlog.

With this model, the squads can move fast on their own, independently of one another and develop specialisation in a component of the product, and this generally leads to increased productivity as developers become more familiar with that component over time.

But it also has its downsides:

  • There is little incentive for cross-team collaboration and the insights into the product is split across multiple teams, leading to a fragmented view of the product.
  • Product Owners cherry-picking stories to ensure enough work for the different teams, which may not necessarily be high value items.
  • Additional coordination overheads incurred to put everything back together from the multiple teams for release.

Our Trigger for Change

Our defining moment for change happened when our major stakeholder requested for all 3 squads to pivot and prioritise grant automation features.

These features were needed in a short span of time (with in a month), as commitments were already made to a few other grantor agencies on the launch date. This sudden notice caught all the squads off guard, with little runway for the other 2 squads (Grant Builder and Grant Processing) to learn and deliver these features immediately.

This incident surfaced a bottleneck clearly — the bottleneck of learning.

Having multiple backlogs for a single product encourage silos, which can make your teams less adaptive to changes.

So… We were lucky this incident was a near-miss, since it was later revealed that the grant automation team is on track to finish the features, without mobilising the other squads. But it was also the catalyst for our team’s transition to adopting Large-Scale Scrum (LeSS), to optimise our teams for learning and adapting.

How LeSS helped the team learn better

For a more detailed explanation of why LeSS is beneficial, you can learn about it here. For BGP’s case, it simply helped the teams learn better and faster through many of the combined events.

You can legislate education, but you cannot compel learning —
a wise man once said to me

The thing about LeSS events is that learning is also made compelling, through the way it is facilitated.

  1. Product Backlog Refinement

Mixing developers from different squads up during this event is an engaging way to learn different perspectives and meeting new people! — while getting user stories ready

In PBR — we have developers from all the different squads coming together to share perspective on how to deliver a user story. We also make sure there is perspectives coming from Business, Development, Testing (3 Amigos)

2. Sprint Bazaar

Setting up stations in a “science-fair” style and encouraging hands-on play of the product makes inspecting, adapting and learning our product a 2-ways interaction, which is engaging and fun for the developers and stakeholders. Before, it was done in a one-way manner as a demo to stakeholders, which may not yield as much interactions (or feedback)

Developers set up stations in different corners of the room, ready to showcase their hard work (in the form of a working increment) to other developers and stakeholders to play with.

Learn more about our journey in implementing a sprint bazaar here!

Measuring success

As we turn to LeSS to address our bottleneck of learning, we are also keen to measure the effectiveness of this transformation. We used Spotify’s health squad model to regularly review how well our teams are doing, which is nice because it has an element of learning in it.

Through a survey that we have the teams fill up every 2 sprints (on a scale of 1 to 5, where 5 indicates high learning opportunities) , we saw a general upward trend in learning over 10 sprints after we adopted LeSS.

From the results, we inferred that our facilitation of LeSS effective and it enabled a structure and cadence for learning.

Benefits

  1. Product Quality Improvement:

Within 1–2 months of adopting LeSS, our squads learned better about the code quality across the entire product as they were exposed to other parts of the product, and through cross-squad inspection, uncovered existing bugs in the system. Surfacing and fixing these bugs gave us a higher quality product.

2. Improved Adaptiveness:

Our squads onboarded the Energy Efficiency Grant within 3 months on BGP, through learning and adapting the existing Productivity Solutions Grant. This helped us to achieve a time savings of 6 months!

A Key Challenge Faced

Agile Contracts hindered our adoption of LeSS

Our existing agile contracts had existing clauses that were binding squads to a particular scope of work for a certain customer. This clause created unnecessary scrutiny by auditors, on whether a squad is working on items outside of their defined scope. This prevented our squads from being nimble and flexible to work on other items prioritised by the Product Owner that may be of a higher value.

An excerpt of an agile contract, which auditors may pick on, that may prevent squads from being nimble and responsive to changes. In this case, the squad cannot work on any items other than those for Customer X.

We managed to overcome this by adapting our clauses to become more outcome-based and empowering our Product Owner to make the final call on features prioritisation.

An excerpt of our existing agile contract, that helped the squads achieve more flexibility to adapt the product according to our Product Owner’s priority

Concluding Words

Slow is smooth. Smooth is fast. — U.S Special Ops Forces

The above quote is counter-intuitive to some extent, and that is true for LeSS as well. At the start of our LeSS transformation, our teams did move slower (in terms of output) as we emphasized on learning and cross-squad collaboration, but after a period of ~6 months, our teams begin to reap the benefits — in terms of better code quality, increased flexibility to deliver work, and adopting a more product-centric view.

I do hope more product teams will consider this framework, although it is not simple to kickstart and implement, but it will help our teams be more nimble and build a better product in the long run!


LeSS Adoption at Business Grants Portal was originally published in Government Digital Products, Singapore on Medium, where people are continuing the conversation by highlighting and responding to this story.