OneWeb: one year on
A year ago we launched OneWeb with a mission to create new digital services and products for our many users.
Remember this? Gorgeous Italian sponge cake with a light meringue cream 😋
We did a lot in a year and a lot has changed since we started – we have had to flex, pivot and course-correct more times than I can count (and this was always the plan). All I would say is that delivering our programme with agility means also leading on change and making some brave decisions in the open, in front of stakeholders, team members and end-users alike.
As we celebrate our 1st birthday, I thought I’d look back on some key pivot moments and lessons we’ve learned as an agile change programme.
From a small team of specialists working in Highfield Campus, we have now become an eclectic bunch of user-centred design professionals including:
- content designers,
- user researchers,
- service designers,
- UX designers
- delivery and product managers,
- and more!
We are dispersed across several locations, including embedded teams in faculties and departments during particular delivery phases.
Not everything was right when we started (but we couldn’t know what we didn’t know). We had no room to grow, no walls to share our thinking, the structure wasn’t quite right, and all we wanted was to share the same space and create a buzz for delivery.
We had to adapt our team’s structure more than once over the past year in response to changing needs of the programme, and luckily we had the built-in autonomy to do so. Every phase we enter creates its own challenges and, although to an outsider there is probably an air of organised chaos, our ability to change quickly is critical in allowing teams to feel empowered, collaborative and ready to deliver.
In an ideal world we would have liked to deliver from one place, but this was not an option. So instead of physical co-location we try our hardest to create a common purpose to make sure that relationships can form and we can still learn from one another.
If your programme involves internal processes that were not designed for the digital age, or with the end-user in mind, you are more than likely to find out about it when you start looking beneath the bonnet of your digital service.
We had many ‘anxiety inducing moments’ (thank you Kate!) when reviewing our vast amount of content and all the missed opportunities associated with them.
This has been the most common feature of our delivery so far. Literally every time we try and address an issue, there is a greater problem lying underneath.
The iceberg metaphor is like an iceberg. (via @simulo)
So, if your service relies on good data, or involves a new API, or needs content to explain a process – rest assured that your team will find out about it in no time.
And to allow all of these to be successful from a digital delivery point of view, you must have some good basics in place:
- a good strategy,
- a cast iron proposition,
And when you need to find a solution and it’s not clear how you can solve the problem upfront, an agile approach encourages you to pick the simplest part of your goal to deliver quickly. This way we can learn from the results, iterate, or fail quickly and cheaply.
We have some really great stakeholders who love getting involved and collaborating with us as part of the programme. Telling the story of change to stakeholders is hard – it requires pivoting on an almost daily basis. The truth is that creating change is dependent on stakeholders who are willing to be the agents of change within their organisation. At times there is too much accountability (i.e. everybody owns a piece of this), and at times, there is too little (i.e. we can’t find an owner for this).
One of the challenges is creating the ‘just the right amount’ of change for an organisation. And the university is certainly no different. It is the ‘Goldilocks principle’ – but that’s another presentation!
We’ve focused on driving change, leading teams, managing up, managing down, managing side-ways, managing diagonally, convincing some stakeholders that ‘digital’ is a thing, and convincing others that there is no point investing in the next shiny but ineffective thing… all whilst trying to be very helpful to leaders and make our point… – mission impossible! It takes a lot of perseverance and emotional resilience, as well as the ability to earn trust quickly with many different types of stakeholders.
In a large and complex organisation there are always competing priorities and if people don’t like what they see, they will find a way to tell us. As ever, this is as much a social project as a technology and design one!
Things can always go wrong, no matter what approach you take. If it’s cheap to fail, why not try it out? That’s the mantra of agile methodology after all.
When you’re facing problems, you need to take inventory of your resources. Whether your current strategic challenges were predictable or unexpected, you must know what you have and what you’ll need moving forward.
So we had to do some thinking and rethinking of technology choices in between phases. Mainly because we needed to think beyond programme funding, availability of specialists and the experience in teams across the University. These factors can often be overlooked.
Sometimes needs and abilities dictate situations and help you and your team bring more to the table, and this is what we had to do in relation to our technology choices. We picked up the best bits from our first creation (and there are plenty of good bits), learned what worked and what didn’t and applied it to a new solution that can be scaled in a cheaper way for our University.
As the business owner of OneWeb, I can’t afford the luxury of assuming anything will go smoothly. It’s essential to prepare for external forces that threaten your programme and organisation, and also to prepare yourself and your team to deal with them.
Maybe I was naive, but I never thought that I would have to plan for a global pandemic in the first year of our existence. In the wake of the emerging coronavirus situation, getting remote working right became the next new pivot.
Agile doesn’t mean unplanned. As a co-located team, a lot of what we already had in place could also work as a fully remote team whilst we are all social distancing in our homes. But how do you make agile work when teams can’t be teams?
We work in sprints: short, time-boxed periods when the delivery team works to complete a set amount of work. Sprints are at the very heart of agile, so we worked extra hard with delivery managers to get sprints right so that our teams could continue to deliver better products with fewer headaches. Sprints also help each team to see how they are contributing to the overall delivery goals and ensuring that what they are focusing on is a priority.
If teams are no longer co-located, there can be a big shift in how people think about their productivity. For remote working to be successful you have to be clear what outcomes the teams are contributing towards. The delivery engine has to be extremely efficient and the product visions have to be clear. But most of all, there has to be trust and everyone needs to be on the same page. We’re apart, not alone.
Nimble, confident, proactive management
Some final parting notes. It’s not that we have anything against waterfall, but in a time of great uncertainty, agile means that I can help to dispel anxiety by gathering my team during a crisis, communicating, and putting our problem-solving skills into practice. Dramatic changes will happen – always. However, good detailed planning and a measured response to prevent collapse is what agile is able to offer you.
Nimble, confident, proactive management. Do the hard work, to keep delivery simple.