The Beta phase of an agile project is where you develop your service for real. The prototype created in Alpha needs to be brought to life with the right infrastructure and support behind it. That’s not to say that changes can’t happen in Beta, of course. It’s not supposed to be the finished article. But some changes are more costly than others, so the key is to plan ahead.
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.
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.
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.
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 NEC Digital 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.”
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.
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 NEC Digital team brings together the user-centred design services of Snook with the proven software expertise of NEC. With end-to-end experience on hand to support every agile phase, we can help clients to build sustainable digital services.
NEC Digital is a partnership of the best-in-class software delivery of NEC Software Solutions with the pioneering user-centred design services of Snook. We offer end-to-end digital transformation expertise to the very highest standards from discovery to development and beyond.