Tiny teams: a woman and a man next to a whiteboard

Agile government: Delivering high quality outcomes with tiny teams

James Patrick

Our last blog explored ‘tiny teams’ and why government organisations utilise these small, agile teams to achieve cost-effective, tangible outcomes. Here, James Patrick, Principal Solutions Architect, shows how Zaizi’s applied this innovative approach for our public sector clients and partners.

It’s often said that small teams can’t work fast, can’t solve problems, and can’t deliver quality outcomes. But as mentioned in the previous blog, small teams can pack quite the punch. Like tiny houses, tiny teams can be bold, beautiful, economically enticing, and highly adaptable.

With the right blend of talent and, crucially, experience, these hyper-agile squads can be a catalyst for change in all the right ways. We’ve proven this in two recent commissions, with a third in flight — using burst deployments of these tiny teams, ranging between two and five people, over four to eight week engagements.

In our industry, we talk about agile a lot. But with tiny teams, it’s a case of walking the walk. There’s little time for ceremony and every action is calculated, laser-focused, and tightly strapped to a time-bound outcome. There is nowhere to hide, so inefficiency — which can and does creep — is constantly on display, enabling more impactive delivery management. 

There’s no transparency quite like it; within the team itself and — most importantly — for the customer. This is where working the problem comes to the fore. 

If you’ve been around public sector projects, you’ll know they come with several well defined steps to take, governance thresholds to meet, and reality constraints to confront. This means things like:

They all come with well-trodden steps that must be followed, from designing scalable, functional architecture, to implementing access management, security, and audit. Without drifting into the unspeakable language of tech itself, it means:  

READ: Agile government innovation: Tiny teams, mighty impact

Tiny teams: efficient and laser-focussed

Tiny teams can’t possibly do all these things in a few weeks, surely? Well, they can. By working the problem, instead of being worked by ‘The Problem.’

At the start of a project, the problem is straightforward: the customer wants to do X so that Y can be achieved. That’s the whole equation a tiny team needs to solve!

‘The Problem’ is the big stuff; standards, assurance, security, risk, tech, which the tiny team doesn’t actually need to solve.

It’s become a norm to spend at least part of a project “understanding The Problem” and playing it back to a customer. The question is — and tiny teams empower you to ask this because of that heightened transparency — Why?

“Our customers come to us because they need to get to a destination”

All we are talking about really is rules, and each of us follows rules every day. Rules come from big problems being studied, broken down, and solved. From standing to one side on the escalators, to not littering, to observing speed limits. We know the rules are in place, and we are reminded of them in short form. If we see the number thirty in a red circle, we don’t pull over, research the full chapter and section of the Road Traffic Act and present it to our passengers before carrying on with our journey, we just drive at thirty miles per hour. And our passengers, well, they just want us to take them from A to B, and trust that we understand (and will comply) with the rules.

Our customers come to us because they need to get to a destination and they trust our driving because we understand the rules. ISO 27001, Cyber Essentials Plus, industry awards, public sector case studies… they know we have a clean driving licence before the engine even starts. These examples of The Problem having been fixed.

Yes, there are a lot of things to consider. That much is undeniable, but they are still just the rules we follow every day. They don’t undergo a polar switch at the start of each project, and keeping up to date is our collective responsibility, which should never be abstracted from a customer’s time and budget.

Do we fully understand the GDS Service Standards and development phases? Do we know what APT28 and 29 are up to in the cloud according to the Five Eyes community? Are we exposed to the latest vulnerabilities and exploits? Do we work through the OWASP Top Ten as a first port of call when conceptualising an application? Are we up to date on NIST CSF 2.0’s changes and their latest updates on Post Quantum Cryptography algorithms? Have we read the government guidance on the public sector’s use of AI? Are we well-versed in the latest NAO guidance on digital transformation? 

All of this is part of the expertise a tiny team demands and it is all stuff that should come in the customer’s packet, not be taken from their pocket.

So, a tiny team packed with expertise doesn’t need to work on much of The Problem at all, just the X and Y. This leaves us with a lot more time – even in very little time – to focus on how instead of what or why. In turn, this narrows the focus down on efficiency.

Public sector case studies

In tech, it’s inevitable that working like this draws the eye to questions such as: Which tooling can we get the furthest with, safely, with these limited resources? There is no space for waste of time or effort, so we do not reinvent the wheels. If there’s a design system, great! That solves n percent of the problem, next! If there’s an innovative, UK sovereign IDE which lets us build, test and deploy robust, secure apps with less people power and time. Perfect!

We’ve asked this question — about how to get farthest with limited resources — ruthlessly and repeatedly over the tiny team engagements and, every time, without fail, we’ve over-delivered, comfortably in time, and built long lasting trust relationships with our customers as a consequence. (Even converting initial sceptics along the way). 

Here are a couple of examples of how our tiny teams have delivered tangible outcomes for government clients through the Home Office’s ACE Framework.

Case Study 1:

We helped a public sector client in the national security space solve a complex problem. We  consolidated an intricate network of data sources into a single, powerful index with access controlled, role-relevant views to drive knowledge sharing and reduce waste. This project combined in depth technical feasibility, user experience design, and business analysis within a complex client landscape. 

Case Study 2:

We supported a national law enforcement customer to prove that a nationwide rollout of a programme to significantly improve the experience of victims of the most serious crimes could be technically delivered rapidly and securely, with accessibility at its core. This project focused on the development and testing of a fully functional, complex application, substantially overdelivering on the proof of concept brief.

For our tiny teams, these projects are exceptional. They’re fun, engaging, and are genuinely reframing what we know about capability, value, and agility — individually and collectively.

These are timely lessons, given international strains and domestic constraints that reshape not only requirements and budgets but the very perception of good value and good outcomes. This drives us internally too because we share the ethos of acting for the public good. Our mission is to make the UK the best and safest place to live and work — and we mean it.

Instead of doing agile, be agile with tiny teams

For us, being a good partner to the public sector isn’t about demonstrating how we are bang on trend to keep our foot in the door with them. It’s about how we can give our customers the right, durable outcome, whether we are with them the whole journey or just for a small part.

The tiny teams approach helps with this by forcing us to gain a deeper experience of the customer’s pain points by applying these constraints  to ourselves — less time, fewer people, no lowered standards, no decrease in demand, no free passes.

“It’s special, what we are doing here, and that’s reflected in the experience of our people and our customers alike.”

This has brought unexpected benefit; the glaring transparency has paid a dividend- in addressing scope creep. Often cited as the reason small teams cannot scale effectively, we’ve discovered it can be dealt with more openly and robustly. If you write good, SMART bids with clear outcomes at the start, spelling out constraints and limitations, customers are clearer on the parameters of engagement and scope becomes self-correcting. This has broken a key ceiling of concern and the model is now replicable, popular and successful.

We’ve learned a lot in a very short space of time — and shared that learning too. Each week, we meet internally and discuss wins, losses, where we’ve adapted or flexed, and, in doing so, we’ve established what will become another set of portable rules. The X and Y of tiny teams, if you will. And at each team health check? Thumbs up and big smiles. We all know something special is happening, and it’s infectious.

You can truly be agile, instead of doing agile. You can work fast. You can solve big and small problems. And you can absolutely deliver quality outcomes. What we’re doing here is special, reflected in the experience of our people and customers alike. 

And we’re proving you can do more with less. So let’s do more of it. As our brand promise goes; Digital government is hard, but together we’ll succeed.

If you would like to know more about how to get cost-effective, tangible outcomes with tiny teams, get in touch.

Thanks for joining us! We’ll keep you informed with regular updates.

Sign up to our newsletter

Consent(Required)
This field is for validation purposes and should be left unchanged.