I found this as a draft from August. I thought I might as well publish it. Oddly, some still stands and some is very very out of date. Curious thing, agile and that.
So. As was covered in Series 1 (aka. The Jukesie era) Beta is an important part of building a government thing. When I joined ONS a year and a bit ago, the idea of this discovery -alpha - beta loop all seemed a bit waterfall to me. Doing a thing for a definite length of time so that you can unlock another level seemed like you might be able to put it in its Sunday best and call it a milestone.
We are now three sprints into our Beta and I thought I would give a bit of a take on that. (Matt has been running his excellent tales as sprint notes, so that will get you into the detail.)
Firstly, I think I am starting to see what a Beta might mean. The main point is that the team are making real things that will see the light of day and will be used by a lot of people. This obviously has an impact compared to the more disposable culture we used in the previous Alpha phase, where things could have much more smoke and mirrors.
We have started the Beta by identifying what an end to end system needs to look like and running towards the bits that looked hardest. The idea being to build a collection of features that could act as a working system. Once that is in place, we can look at where the gaps in the system are and what additional functionality is needed. The key here being to build end to end quickly, but not in such a way that creates any technical debt. Features, not hacks.
To try and build this, we have expanded our internal team with a service one. In this instance, a service team being a fully formed Agile team that can work on premises to help expand productivity.
One of the things we have been keen on is ensuring we don't just bring an external team in building all the new fun stuff and have a staff team dealing with ‘just' bug fixes on our current site. It didn't seem like this would help build a good work environment, but also would create a handover challenge at the end of a project.
So, we have split into three Agile teams (we were one), called them A, B and C (catchy) and striped the internal and external resource across them. The ons staff have been set a rough goal of 50/50 business as usual to Beta time in sprints and the service team 100% on the Beta, but we have wrapped all the sprint tasks together. We are using a single trello board, with a lot of columns to give a signal view of the three backlogs and in sprint activity.
The two week sprint stories are also on three different physical boards. We have spent some time iterating a definition of ready and of done.
Communication of a Beta has really been on my mind. We are doing end of sprint show and tells, but they are quite insular and act as a way of sharing work across the three teams and some immediate top priority stakeholders (I am referring to myself in the third person here). We have also added a dedicated show and tell to internal users most impacted by the work and bigger, more carefully crafted updates for the wider business that can be booked via staff on eventbrite.
Our user research is another key component of communication. We have an ambitious target of undertaking some in each sprint. This project broadly has three big groups. Internal data production, internal data publishing and external users of the system.
For our external users we are attempting a shift with how we approach the testing. Instead of treating a statistical user as a generic type, we are trying to ensure if we, say, test with experts in economic statistics that they are shown real economic data. This helps to avoid statements like ‘if I was a user of this data, I expect I would click here’ and turns it into something more realistic. In these early stages, this is hard to do as the UI is pretty much click through, but it is within our play book (the play book is also mainly in a few people's heads, hence writing this post and others like it in the future)
Our internal users are just as important, but are obviously easier to get hold of (shouting ‘who has an opinion on the ons website’ whilst stood in our staff coffee shop would create quite the response)
To try and get the best turn around on our user research the reporting overhead is as low as we can get it. A Google doc (which is pure gold) and a quick show and tell to the team. Our Ux team and frontend developers sit in the same Agile team so we can achieve a sketch - html mockup - real journey many times in very rapid cycles
One of the things that has really jumped out here is that having a TV, a bunch of things to plug it into and some stools is vital. Even just making sure we are really disciplined in having the right cables always available makes a world of difference
Obviously we use Slack as well (obviously) and this tends to be the usual whirl of gifs, automated info and genuine back channel for any remote workers
I was going to cover Cadence and planning here but I can hear Mr Jukes from series 1 saying ‘the thing is mate, any over 1000 words is a book’ and will take that as a time to pause and treat that as a whole new post.