Weeknote 4: Kanban time, show the thing, and increments or iterations?
This week has been mostly about internal discussions on user stories, delivery and process. I also had my second UX project lifecycles workshop as part of my degree apprenticeship. And I started to break down and plan the assignment I need to complete for this module a bit further.
Iterative vs Incremental
As part of my reading list and wider research this week I’ve been researching project lifecycles and UX’s place within them.
So many lifecycles and methodologies just disregard research and design or try to crowbar them in somewhere. It’s interesting and I think it shows in the literature that it’s difficult to fit UCD practices into lifecycles, especially into Agile methodologies and frameworks.
But it got me thinking about a lot about our lifecycles and in particular the fine balance between incremental delivery and iterative delivery and what’s best for value and outcomes over output and process.
I think there’s no right answer for us really. It depends.
Take a service I’m working on. We’ve deliberately delivered this large service in increments over iterations. And for good reason. We had timeline constraints that meant certain parts of the service needed to be ready so that it could support policy reform work. We had a deadline to work backwards from, and we had a linear business model which dictated certain service capabilities by certain dates. Bringing increments instead of iterations let us release the bits that were needed first, in high quality, and most importantly, in time.
There are a few drawbacks…
· Increments took Big Design Up Front (BDUF) quite often, especially after discovery and alpha experiments.
· It makes it really hard to pivot away from a direction that isn’t optimal further down the line because it’s in use, and has data and processes that depend on it.
· Introducing change can be tricky. And expensive.
· Being in an incremental mindset can drive delivering increments in increments, instead of iterations (I know that’s a mouthful). Meaning you can deliver chunks of functionality that don’t solve any problems.
Iteration means delivering a “light” version of something (as opposed to a chunk) and then rapidly improving parts of it until — well, until something makes you stop.
You can combine incremental delivery and iterative delivery, especially on large projects. E.g. you may chunk up the wider service or product into increments as we had to, but then deliver a stripped back version of an increment, learn about it, then iterate on it and deliver a better version.
Importantly, iterative delivery is focused on allowing a user to achieve a full task in the simplest way possible. The goal is always to drive behaviours and outcomes. Where as increments, often allow the user to complete one part of the wider task, before we then go on to deliver more parts of the service.
Iterative is lean. And adds value and learning quickly. I think it should be preferred over incremental where possible.
We’ve had so many good conversations about one of our increments this week, across product team, UCD and development. It’s great to flesh these things out and make sure we’re optimised to deliver value to the business and great experiences to our users, whilst also juggling competing project priorities.
Show and tell
We’re hosting our first X-Gov show and tell session next week. If you have an email ending gov.uk you can register here.
I’m presenting some initial designs on an increment of our Subject Matter Specialists service and our lead developer is presenting some work on an API using serverless architecture for our Register of Regulated Qualifications work.
So this week has been getting some slides together and practice in. More to do next week.
Also, don’t forget to give our card sort a go.
More stickers
In Weeknote 1, I mentioned some stickers. They’re lost in the post, so Rob has kindly ordered some more to be sent directly to the office. Frustrating! We’ve got a pretty cool design, although puns have since been banned from future stickers. I wasn’t go to post the design until I had a sticker stuck to my laptop. But I can’t delay any longer…
We ended the week this week with another fun sticker storming workshop across multiple teams in Ofqual who have been working on our Statement of Compliance service which went live for 2023/24 recently. It was a great way to finish the week, we’ve settled on an interesting metaphor, and Phil, our senior interaction designer is going to take the lead on designing this one, so I know it’s going to be awesome.
Kanban
At Ofqual, we’re moving away from Scrum and trying out Kanban, as of this week. So I’ll no doubt be documenting some of that change over the coming weeks.
This week’s reading
Finally finished Lean UX — lots of helpful things to take from this methodology. Especially around testing and experimenting our riskiest assumptions and prioritising what the least amount of work we can do to test those is.
Started on UX for Lean Startups — also on the uni reading list. But feels a bit too removed from my work in a regulator so far.
Some background reading on project lifecycles. Revisiting my APM book of knowledge!
Mostly sacrificed reading though, this week, to learn some more Javascript. Could do with recommendations for the best courses available!
Previous weeknotes
Weeknote 1: Getting started in user-centred design
Weeknote 2: UX apprenticeship enrolment, back to the drawing board, and OOUX
Weeknote 3: Design system day, working with the best team, and the first week of studying UX
