Digital

I recently spent a year on secondment to Scottish Parliament working, as part of its web and online project, on content for its new website.

I’m glad I did it and if you’re thinking about a secondment, go for it.

As well as learning more about how the Parliament works, my time in Holyrood:

• gave me the chance to share what I’ve learned about content design at the Scottish Government
• helped me identify my aspirations and priorities
• helped me identify the aspects of content design I enjoy most

It also gave me the chance to work with a different collection of helpful and supportive people who were generous with their time and knowledge

They reminded me that being user-centred is not just confined to user-centred design professionals. It’s a curious, creative and empathetic mindset, as well as something you do.

Here are the rest of my reflections on my secondment.

They’re less of a blow-by-blow account of the time I spent at the Parliament, and more observations and musings about Agile project management, content design and team working that were prompted by the good practice I saw while I was there.

Content without user research and usability testing is fiction

OK, maybe not fiction. More a made-for-TV movie that’s based on true events.

If users haven’t been involved in developing your content then it’s pretty much a well-meaning stab in the dark.

While I was at the Parliament, I worked closely with user researchers during discovery to find out what users needed from content.

And there were 2-3 rounds of usability testing with internal and external users for each section of the site. Because I was able to sit in on them, I was getting much more than my 2 hours of user research every 6 weeks.

Every usability testing session I observed confirmed that listening to users is where the gold is. Nothing beats:

• hearing what helps, frustrates or confuses users in their own words
• seeing them struggle with something you’d assumed would be obvious
• being able to ask them follow-up questions

It’s also an important reminder that:

• you’re not designing for yourself, your boss or subject matter experts
• if whatever you’ve created doesn’t work for users, it’s useless and storing up future failure demand

Taking time out from delivery is helpful

Having retros at the end of every sprint is good in terms of taking stock but, if it’s possible, it’s also helpful to have ring-fenced time away from what you’re working on.

During my secondment, my team attended a 2-day Agile for Effective Teams course at CodeClan (a digital skills and training academy).

It was time well spent, because it:

• wasn’t a one size fits all course – what we were learning was directly related to our work context which made it meaningful
• clarified some Agile concepts I was hazy about (sizing, anyone?)
• it was led by a trainer who had a wealth of experience in Agile AND Waterfall projects
• was a chance to find out about other team members’ experiences of Agile – something you don’t usually chat about day-to-day
• was a team building opportunity

The course also gave us time out to learn processes and practices that would improve the way we worked as a team, without the distraction of meetings, requests and day-to-day work.

It was a great thing to do, because Agile’s not just about what you do and the speed you do it at, but how you do it.

Building and maintaining an effective team takes work

It’s a common misconception, but shared goals alone do not a team make. Like houseplants, teams need to be nurtured.

As well as being from different professions and having different learning preferences and thinking styles, most team members have:

• different experiences of team working
• varying levels of understanding of what the other the professions in the team do
• baggage from previous jobs
• different ideas about what a good team/effective team working looks like

These things, and the unspoken assumptions that underlie them, mean that relying on team members being ‘adults’ and ‘professionals’ doesn’t always work.

Team cohesion isn’t something that happens by accident, and it’s not just about frequent visits to the pub (although that can be fun). Some ingredients are:

• creating psychological safety (an environment where people feel comfortable saying what they think without fear of being judged) although, for various reasons, it can be difficult to develop this
• respect for each other’s part in the design and development process and a willingness to discuss your decisions
• genuine collaboration as opposed to tokenistic consultation
• openness to having safe discussions about issues and challenges (talking isn’t always communicating)

There also needs to be honesty about whether these building blocks are in place and, if not, why?

While I was at the Parliament, my team was always open to any ideas and suggestions for ways we could work together more effectively.

No content management system (CMS) is perfect

I don’t have much to add to this point really, apart from, the better the quality and frequency of communication between the people building a CMS and the people using it, the better the product.

Project communication needs to be planned

This is common sense, but not always common practice.

Communication is one of the things that always slides to the bottom of the to-do list. (I’ve been talking about writing this post since well, let’s just say for a while now.)

We have deadlines to meet, so we prioritise doing the work over telling people about it. But if we want to take, instead of drag, our colleagues along with us, they need to know what we’re doing, why and how it affects them.

Ad hoc, self-congratulatory announcements are counterproductive. Stakeholders, and the wider organisation, need regular, relevant opportunities to find out about your work. This means they can comment on it, agree, disagree or suggest ideas. They don’t need PR delivered in Agile-speak.

To make sure this wasn’t the case, business analyst colleagues at the Parliament put together a communications plan that supported the web and online project’s goals.

Death to Waterscrumban!

What’s Waterscrumban? The confused child of Waterfall, Scrum and Kanban. It often looks like this:

• sprints with no sprint goals
• overly long sitting ‘stand-ups’
• Kanban boards with tasks instead of user stories on them
• Kanban boards with no work in progress limits or backlog
• enormous volumes of documentation
• sporadic retros
• no burndown charts

I’m no Agile purist but, pick a team! (While I was there, the Parliament was Team Scrum.)

Taking the Project Management Buffet approach probably means you’re not getting the most out of any of the techniques you’re using.

Don’t forget about the principles of Agile

Day-to-day it’s easy to focus on stand ups, show and tells, whiteboards and post-its.

Possibly because things like taking part in Agile ceremonies, setting up processes and making progress on work that you can point to, is relatively straightforward.

But this means we often lose sight of Agile’s values and principles. (This is another reason why the CodeClan course we did was useful – Agile’s values and principles set the scene for what we did.)

It’s often the values and principles that are less tangible and more difficult to measure that languish by the wayside, like:

• individuals and interaction over processes and tools
• support, trust and motivate the people involved
• enable face-to-face interactions
• simplicity
• regular reflections on how to become more effective

That’s why, in retros, it’s good to devote time to seeing if these principles are being upheld, as well as focussing on quick wins.

It’s good to make contact with colleagues doing similar work

While I was working on content on parliamentary committees, I got in touch with a colleague at the UK Parliament who was working on the same subject. I’m glad I did, because he was incredibly helpful.

His team were about 18 months ahead of us, so he had lots of valuable information, ideas and reflections to share.

He took the time to talk me through the process they’d followed, the challenges they’d encountered and their prototype. It was great to have the chance to speak to someone in a similar institution, and working in a similar role and context.

I also spoke to colleagues at Scope about their approach to content testing. Their process differed from ours and it was good to hear them describe how it worked in practice.

As well as getting information and advice, connecting with colleagues is useful because it can prompt you to look at what you’re working in a different way. And it’s always reassuring to find out that everyone’s dealing with similar issues.