A content team's Agile journey
Our previous website migration projects had been messy, expensive, long and in some cases, disastrous. This time it was going to be different - how we used Agile to move a mountain of webpages on time, on budget and on our own.
Migrating the website
Our website was a bloated 3600 pages of content of various quality and usefulness. We had other sites too which had always been separate to the main one. We wanted to bring all the sites together under one website to help with linking to content instead of a very bad habit we had of duplicating information. The main site needed to be the One Source of Truth and other sections and sites needed to link to that information rather than duplicating it. That, as you know, would be better for the users, for search engines, for authors who need to maintain that information and very important for being a dependable, authentic, valuable website.
When we thought about the way we had used Agile to successfully deliver the new homepage template and components, we tried to shoe-horn the rest of the website content migration into that same model. We discovered that we couldn't so-easily define the stories (tasks that needed doing), or how the Product Owner and the Content Team Lead would work together (things just weren’t as clear-cut anymore). We needed answers to questions, such as how could we move the content between writers, stakeholders, and publishers? What tools should we use to communicate with each other? with stakeholders? How on Earth were we going to divide up the work?
It wasn't until we realised our Backlog - which often lists the prioritisation of the functionality of a project - was actually the content itself. And our Product Owner’s priority was no longer functionality, but our customers.
We could see the current content on the website, and after some quick figuring, it was decided the number of writers and CMS publishers we would need to complete the task in the time available.
Note: Agile often doesn't have deadlines. This was one of the ways that Waterfall bunted against Agile during the project where senior management demanded a deadline and we had to acquiesce. At least it made the figuring easier, if not the work.
We seconded some writers in from parts of the business and hired two more on contract. We also hired two people to construct and format the pages.
We created a content team:
2 full-time writers
2 part-time writers
2 CMS publishers
1 content producer
1 team leader
We cherry-picked the parts of Agile that suited us and got going:
The stories became the different sections of the website. Instead of the typical Agile story "as a <who am i> I want to <do something> because <benefit or value>” our stories became discrete sections of the website.
Information Architecture (IA) became our bible.
We had a stand-up meeting every day in front of the board and moved our tasks from left to right.
We worked closely with the owners of the content on the website, rapidly becoming experts on the website.
We had a Content Lead who was fantastic at creating spreadsheets to track progress - first based on the original IA spreadsheet, then to more sophisticated tracking spreadsheet magic
We published content to the website as we finished each section
We had a Retrospective at the end of the sprint, and learned from our successes and changed our approach when things didn't go as well as they could have
We stood up at Showcase at the end of each Sprint and let everyone know what we were doing, what we had done, what was next.
Tools
Some of the tools we used:
Slack: Real-time messaging and file sharing. (Preferred over email.)
Zoom and Skype for business: Video-conferencing, and screen-sharing.
Google Docs for content collaboration.
satellite websites - Google Doc folder.
satellite websites IA - Real-time progress information on migrations
Content Road Map - forecasting what we expect to deliver in future sprints
Content Sprint
Our content sprints were the same length of time as the delivery team. Three weeks, or 15 business days.
Day One: Planning
The Product Owner typically provides stories that we, the team agree to work on during this sprint. Our Content Lead represents the Product Owner in our Content Team. As a team, we decide which sections of the content we will work on in the coming Sprint and the effort required to deliver each story:
Discussion of each story (how many pages, level of complexity, are there tables, video, downloads etc)
Estimate of effort based on points (Fibonacci numbers)
Agreement and documentation (Google Docs/System cards)
Each story is then noted on a system card, along with the tasks required to complete the work, the person responsible for the work, and the points of effort we agree the story is worth. After the meeting, each story card is added to the left-hand side of the Content Team’s Board in the “stories" column; along with a post-it note for each task in the “to do” column. These post-its are moved during daily stand-ups as the tasks are completed.
We also discuss any issues raised from the previous retrospective and how that might impact our ways of working. The meeting helps us to understand our capacity to deliver on our promises.
Daily Standup
A short meeting held at the same time each business day and adheres to a set protocol. Anyone can attend the daily stand-up but only members of the team may speak. Each team member gathers at the Content Team Board and reports on tasks completed against each of their stories:
what has been achieved since the last daily stand-up meeting
what will happen before the next one
any obstacles to sprint goals.
Weekly
Weekly meeting for Content Team to discuss any Content production and/or publishing issues. Anyone in the Content Team can add something to the agenda. The existence of this forum means we don’t spend time going into detail on non-urgent matters during the week, i.e. “Let’s talk about this at the Content Team meeting.”
Mid-sprint “Eyes-up”
Midway through the sprint, we have added a quick "Eyes Up" meeting to see how we're tracking towards that goal and adjust accordingly.
Retrospective
A safe environment for members of the team to share what worked and what didn't work during the last sprint. Each team member spends a few minutes at the beginning of the Retrospective to document (on individual post-it notes):
What worked well in the sprint
What improvements could be made
Shout outs (praising people for good work)
Each team member hands their post-its to the Scrum Master with a short explanation. The Scrum Master groups the post-its so we can identify patterns and trends. He documents all that is said in the meeting and implements action steps for improvement in future sprints.
Showcase
Open to all and held at sprint’s-end to show accomplishments of sprint/project.
We've created a new homepage and website, we've assessed every page of content and edited, rewritten or deleted as needed. If we'd done only that, we would have a successful project. But we've done a few other things that we're so proud of:
broken down silos
earned the trust of our management
built a successful content team culture
The Golden Rules of the Content Team
These are some of the things we’ve learned so far on the Content Team.
Accessibility
Responsive Design
Not all content is equal
To have a great website we need great publishers
No one knows as much as all of us
‘The website is not the answer to all of the business’ problems
We are learning and working at the same time
Minimum Viable Product (MVP)
Our business is not an agile environment
Aim for “better” not “perfect”
How we get things done is as important as getting them done.
The divisions or departments are not all the same.
Photo by Lala Azizli on Unsplash
Working in Agile, how it feels
This can be an uncomfortable way of working, and it is different to what staff were used to. This discomfort is caused by not having all of the detail upfront, and having to trust the process and other teams.
As we continue on the project, we have recently created ten new website homepages for our migrated satellite websites. The satellite website migrations into the main website add another layer of complexity. Agile works best when teams are co-located, and we are not. We need to manage this discomfort and there are two things we need lots of, transparency and communication.
Five ideas to take back and integrate into your teams tomorrow:
culture of self-directed experts - let people be good at what they're good at. Let them take responsibility for the promises they make. Remember, you don't have to wait to be told what you do, but you do need to let people know what you are doing.
co-locate - don't underestimate the benefit of physically sitting close to colleagues. After all these years of talking about digital nomads and people working from home, it's amazing to find that actually, having a team all sitting on the same floor in the same building actually fosters great cooperation and keeps communication friction from slowing things down.
communicate - get up and talk, ask, pick up the phone, ping someone on Slack, dial-up zoom and talk via video. We've learned to communicate so much during this project, its amazing to go back out into that Waterfall world and see people sitting there waiting for an email to come back. Voice. Voice. Voice. use it.
confidently share - let everyone know what you're doing. Talk and write and post and present. Be transparent. Colleagues can read our wiki, we have pages on the intranet where we upload showcase slides and have our contact details everywhere. We upload to Yammer, and Slack, of course. We present to groups, talk to meetings, include as many people as we can. We make it part of everything we do - it's not extra - it's threaded through everything.
consistency - the difference between a high performing team and teams that aren't is consistency. We have our stand up meeting every day. Everyone is there, every day. we want to be consistent, we want the cadence, the rhythm of our sprints to keep us moving forward.. we've noticed other teams we work with who think “aw let's not bother meeting today, we're all a bit busy.” Or “we don't see the point, or there's nothing to update..” then they don't meet today, or tomorrow, then it's been a week, it's been a month and then they're fragmented and not working cohesively and it's as simple as being consistent. Saying what you'll do, then doing that thing. That's really all anyone will ever ask of you. and hold each other to it.
We tell our stakeholders how much we enjoy working in Agile and find they do too.
We develop relationships with our subject matter experts and stakeholders to encourage them to let us know if they're feeling uncomfortable, to keep telling us and we can do something to address it.
That benefits you, us, and any future partners.
