Managing Content Development Projects in Agile-Like Environments

Bonni Graham Gonzalez began noting that agile is all about letting people be good at what they do.

There's a definition of "agile" and there's how everyone does "agile." It's a group of software development methods based on iterative and incremental methods where requirements and solutions evolve through collaboration between self-organizing and cross-functional teams.

Extreme programming and rapid application development are variations on agile. Then there's "FrAgile," where we've thrown requirements out the window and everyone just hurries a lot. Also known as "kill the developers."

Where does content fit in? Ideally, in from the beginning. Should be in stand-ups and scrums.

The advantages of agile is that it's inherently iterative. Things change so quickly so we know the content we create first won't be what we end up with.  It can be easier to create embedded documentation (if you're in the early user story creation stages).

So many error messages admonish the user instead of trying to help the user.

There are challenges. You MUST practice minimalism. You must start layering and prioritizing of information.

When people go to any type of content, they have questions. But they don't wake up in the morning thinking that they want to read documentation. Those questions boil down to four key elements. What is it? How do I do it? Why do I care? What just happened? These questions give the opportunity to prioritize content creation based on what you know about your users. You can add more layers later. They don't have to be all in place all at once.

If users understand why they are invested with a feature, they will muddle through.

Buyers are dumber than we think they are, but users are smarter.

Other challenges include not often being able to "touch" working software before we get started, at least for the first few sprints. And team burnout. If you're working in an environment that you need downtime between releases, it's exhausting.

It's not necessarily bad for docs to not start until the second sprint. 

We're all making agile up as we goo along. Even the teams who do it really, really well.