The Beta phase is where you see your agile project in action

Building for real in the Beta phase

The Beta phase is where you build your new service. That new service might be a small extra feature or something completely new, but both need to be tested with actual users. There’s usually two phases to this phase. There’s private Beta, where a select group of users test that it meets their needs. And then public Beta, when it’s made available to all relevant users.

You’ll move your service to Live only when it’s been used enough to check it’s right. That means the time you’ll spend in Beta depends entirely on what you’re building, and for who. It’s not unusual for some services to stay in Beta for years.

Get everyone on the same page

If you’re working with a partner for your Beta project, it’s worth getting into the fine detail at the start. We’ve build digital services for government agencies of all sizes, and time spent clarifying what terms mean is never wasted. Is it private or public Beta, or both? Which user groups should test first, and why? Who’s providing helpdesk support? At what point does the provider step away? Talking about these issues up front, right down to checking the meaning of technical terms, will save time and money in the long run.

Design in cybersecurity

We always consider cybersecurity in Alpha, but in Beta it’s non-negotiable If you’re going to be operating the Beta yourself, make sure whoever built it considered resilience and the lifespan of the tech stack itself. Will you need multi-factor authentication, for example? Will the testing database go out of support in three years? Bolting cybersecurity on at the end can be done, but in our experience that comes at a cost.

Engage your stakeholders

In Beta, there’s a temptation to set things in stone. You’ll spend money at a faster rate than in any other phase, so the certainty looks attractive. But with agile development, you’re still on a learning curve. And the best way to learn is to keep stakeholders close.

Jo Harvey is part of the team and has worked on Beta projects of all kinds, including for the Youth Justice Board:

“Beta can be intense and highly technical, so it’s even more critical to work in the open. Hold sprint reviews with anyone who will sign off features or budget further down the line. Talk to users. Get the support team involved from the start. Every engagement will flush out opportunities and constraints, and the sooner you know them the better the result.”

Appoint a Product Owner who can advocate for users

If you haven’t already got one, a Product Owner is a key role in agile development, although it’s often overlooked. Product Owners are perfectly placed to balance the needs of users with the business goals and development constraints. If features need to be scaled back to make the budget work, they’ll make sure they’re the right ones.

We’re sometimes asked to deliver that role on behalf of our clients. Often, it’s when the expertise isn’t available in house. But if the choice is there, we’d always recommend they sit on the client side.

Plan to learn more

Once you’ve passed the service assessment to take your project Live, the work doesn’t stop. User needs change, technologies develop and the service itself will likely evolve. That’s why the our studio brings together user-centred design services with software expertises. With end-to-end experience on hand to support every agile phase, we can help clients to build sustainable digital services.

This article is part of a series looking at the different phases of agile projects. Find out how to get the most from the Discovery and Alpha phases or get in touch with our team.