Agile and content? Is this even possible?
Is it possible to mix business with developers?
I think there is a way, but it takes some tweaking and patience.
First, what do I mean by content updates and why am I mentioning developers? What do they have to do with content? There seems to be a lot of confusion about this. Most software development is about the functionality – the app itself, not about the message/communication/words for which the app was developed to share. Content exists in every app, but content should not exist in the code (and it does – all the time and everywhere – thus the need for developers to do content updates). This happens because developers see content as extraneous to the functionality. We need to move away from our fear of content “messing up” the app dev process. We need to focus not only on the functionality but also on the (content) editor experience. Having a wiz-bang awesome app that bounces you to some other website for its content is a really bad user experience. Content is what your app is saying. It’s what your business wants a particular audience to know. And it’s just as important as the functionality the app is providing.
Way back in 1996, Bill Gates coined the phrase, “Content is king.” He argued that content is where the real money is on the internet. Without good content, you don’t have customers. I feel like most businesses got that message and hired content creators, but they were silo’d from the technology folks. It’s almost like there is a big brick wall between them and developers toss over technology solutions and content producers toss over words but neither side truly understands the contributions of the other.
Most apps today accommodate content, but at what cost? Who’s going to maintain that content? While the content producers are the subject matter experts for the content, they are often not the people in charge of managing that content – sometimes this is by (poor) design and sometimes because the system is too “technical” for the content producers to use (i.e., a bad editor experience). By “too technical,” I don’t mean they can’t learn it, but if it’s not something they log into and use often, then training doesn’t matter – if they have to relearn the system every time they use it, it’s “too technical.” So, a developer is often the one straddled with trying to code the content to meet the desired specs from the content producers.
Sometimes, the content producers are provided with a content management system (or interface) that usually has a pretty awful editor experience (because the editor experience is often created by developers for developers – not for business folks). Updating content becomes such a chore, a developer is brought in to make updates for the business simply because the solution never considered the editor experience.
But I digress. This post is supposed to be about managing content updates in an Agile way.
Kanban and content updates
When an app is built in such a way that content has to be coded and uploaded via antiquated FTP, you usually need a technical person (i.e., developer) who makes sure there’s not a stray apostrophe or unclosed div somewhere so the content renders on the page as it is intended. Or, as mentioned above, you have a content management system that has a complex and convoluted editor experience it takes a developer to understand how to use it. We are going to assume, that a perfect world of well-designed content management systems does not exist. Yet. I remain hopeful, but I have yet to actually see or experience it. Thus, the need still exists to manage content updates in terms developers are used to.
I won’t go into an explanation of Kanban or Agile. There are plenty of explanations out there. Suffice it to say most software development today follows an Agile methodology.
But content updates are not software development despite the need for someone with developer skills to make the updates. Content updates are messy and rarely come to you in a “ready state.” As much as you want to train the business to provide those updates in a ready state, there are far more exceptions than rules in the content game – as it should be. If content were as structured as object-oriented programming, nobody would read it. Content evolves almost constantly. Content needs evolve. The developer making content updates not only has to know how to translate those needs to code (remember, they are needed because someone developed an app in which the content is embedded in the code), but also keep a literal library of exceptions in their head. Very soon this person becomes a fountain of institutional knowledge that silos those updates into a bottleneck. If Susan in the business says, “fix the date on that page I sent you last month.” The developer, with the head full of institutional knowledge, knows exactly which page and where the date is to which Susan refers. However, because all this knowledge is sitting in that developer’s head, it makes them either indispensable or, more likely, exhausted. Here’s where Kanban can help.
Content Kanban
Here’s what a basic Kanban board can look like for content.
Two things you’ll notice – the Backlog Graveyard and Review Stalled. These I want to talk about because they are the nature of content updates.
Backlog graveyard
It got its name because this stuff is going to come back and haunt you if you don’t keep track of it. You don’t want to delete or archive these kinds of requests (except maybe once or twice a year) because they often come back in some form, and it will save you a great deal of frustration and time to have updates to your cards rather than one person holding all this info in their head (institutional knowledge).
Very often with content updates, the requestor has what they think is a “simple” request. Once you groom that request and have a few meetings it becomes something a lot bigger (or it’s huge in the first place). In the software world, the response is “just break it up into doable chunks and keep it going on your board.” That’s nearly always not the case for a content update. Remember. Content updates often happen outside of app development (and long after the app is “complete”), but a lot of items in the graveyard are dependent upon some new application or feature development and you can’t really move forward until another team completes those requirements.
So why keep it in the graveyard? Why not just close it and move on? Because development probably won’t happen as fast as the business hopes and you’re going to have to create some kind of interim solution in the meantime. And that item will get adjusted and moved back into the backlog.
Similarly, very often, the business makes broad requests of the content team that no content team can handle alone. This is another reason to keep them in the graveyard. For example, you might get a request to remove all PDFs from “the website” that were published before a certain date. Ha! First, there is rarely one single website. There are usually multiple, and they are spread out all over the place. You can’t possibly, single handedly or even team-wide, remove all such documents without significant resource investment (both within and across many teams). So, you put it in the graveyard as discussions are had about how best to approach the problem.
Maybe the graveyard should be called the junk drawer because that’s kind of what it is too. Having a record in the graveyard/junk drawer is helpful because these kinds of requests will come back around to haunt you or, like that one Command Strip sticker you need one day, is found stuck way back in the corner of the junk drawer. Weeks or months after these requests are made, someone will ask, “Hey. What’s the status on that gigantic request we made that we never provided resources or funding to complete?” You have your notes in the graveyard.
I know. I know. You Agile aficionados are vibrating in your seats. “But, but but what about the analytics for the board? You just killed them by housing all that stuff indefinitely on your board.” Yup. We did. You need to get creative with your board analytics when you deal with content. As I said earlier, it’s not software development and it’s rarely an iterative process. It’s messy. Maybe that’ll be another post someday. Capturing analytics from a messy content Kanban board.
In the end, your graveyard will be a place not where ideas go to die (as the name applies) but a place to wrangle all your ghosts. They’ll pile up for sure, but when the time comes you will be able to document how much time you’ve spent chasing down solutions for incomplete projects – a good argument for better process in the future and teaching the business and leadership that simply asking, doesn’t mean it can easily happen.
Review stalled
Now you may be asking how is “Review stalled” different from the graveyard? It’s different because most of the time, these items move on and don’t linger, but you want them out of your review lane because the review lane will get cluttered with all the items your business hasn’t reviewed. (Yes, you can add blocks to them, but the lane will still get crowded and messy.) It happens. A lot. Much like the army, content updates are a lot of hurry up and wait. Requests are made and given utmost priority, your team drops everything, reprioritizes work, does the latest priority update, only to be stalled by the business never getting back with their approvals. “Review stalled” is a way to track the amount of your time spent waiting beyond reasonable deadlines.
So yeah. It’s clear. Your SLAs will be blown up because people won’t get back to you in a reasonable time frame. This is the norm, not the exception so account for it. Set your SLAs super high and over deliver when you can but be prepared when you can’t. If the business doesn’t approve it and you can’t take the change live, leaving it sitting out there is not always an option. I’ve seen on more than one occasion an update was made to some content, it’s sent out for review and the business never gets back to us. It’s left in dev “waiting for review.” Then, months later, another update comes through for the same content and is completely different from the changes you’ve already made. Which one’s right? Does the business think we’ll add this new update to the old or does this update overwrite the old? That’s why we don’t just “leave it out there.” Also, if the business misses the deadline for review, that doesn’t mean when they do eventually approve changes their request goes to the head of the line. You will likely need to reprioritize that work and communicate out a new date and get a lot of flak for being “so slow” with your updates. Again. This is the norm, not the exception and it’s not very fun.
Welcome to the world of content updates.
Process
Some, if not all, of this pain can be alleviated with good process. You can teach the business how to partner with your team and stop your team being treated as short order cooks on a perpetually busy night. It takes time. It takes relationship building and it takes providing a process that works. Alas. Another topic for another blog post.
Meanwhile, give it a go. I think you’ll find it’s nice to constantly have a 50,000′ view of the state of content updates at any given point in time – complete with ghosts and overdue items. And, more importantly, all the institutional knowledge is documented in your cards. Kanban boards are searchable. Use tags liberally. Being able to pop on your board and give someone “proof” that content is messy will serve you well.
