If I were in charge... journalism and technology would not just become better connected, but the newsroom culture would take on best practices that have worked well for software development. At this year's Online News Association conference, a pre-conference session discussed how to relate agile software development best practices to the newsroom and a conference session reiterated the value of #fail.
- fail fast
- fail often
- fail smart
A shortened planning window and iterative approach to development would allow newsrooms to learn quickly, fix mistakes, and adjust to changing conditions. And we already know how to do this: a breaking news story.
Breaking news stories (on most news sites) are a case study of iterative development. The story quickly moves through multiple stages--tweet, to blog post, to fleshed out blog post, to starter story, to longer story, to next day story for the print edition. At each stage there is an opportunity to fix mistakes, add context, and make adjustments based on additional information or reader feedback. The story does its job in the moment giving readers up to date information and contributes to the development of a solid final piece.
To plan for this iterative development:
- Break the project into segments
- Roll out the project in stages
- Build detailed requirements and flowcharts for newsroom workflows and processes
Iterative development helps you get to the point of publication quickly, so you can be agile and fix and learn from your mistakes easily.
- Stay on task: Daily standup meeting
- Document, document, document: Tools to help track progress, issues
- Keep on task: Display and communicate about your plans, workflows
The tool I find most useful for documentation is trac, a customizable ticket or bug tracking software. I use it to track tasks on my to-do list and problems with our website. By logging a ticket, it creates a single page for all updates to the task or problem, and is a way to start building a knowledge base of FAQs as part of your everyday workflow. Each ticket also includes a field to give it a severity or priority level, to say what kind of ticket it is (question, problem, task, etc.), assign it to a person, and you can add additional details such as keywords, people to CC to keep apprised of the issue, or customizable fields like a deadline.
This documentation helps with personal accountability, transparency of tasks, and team communication.
A functional, supportive, and collaborative team environment is vital to building the pathways for evaluation that ensure that we actually apply lessons learned from failure.
- Quality assurance: Engage your reader community.
- Staff to staff "code review": present feedback and suggestions.
- Follow through: Be transparent about updates and accountable to one another
This may be the most critical step in embracing the fail culture. Making mistakes is just a lot of wasted energy if the lessons aren't applied, and if we're the only ones judging what mistakes even are. Quality assurance testing is a critical step in any software development project, and lucky for journalists readers are constantly testing our work by reading it. As we increase transparency and openness, we can also build community engagement into the development process.
On the staff side, a journalist version of code review could help all editorial staff contribute to and be invested in the process. In software code review, the whole team reviews the actual lines of code of a project. A variation for journalists could be for staff to do presentations to one another--project a blog post and discuss how it did a great job with curation, show photos and talk about best practices on composition. The key parts of this review are that all staff would be involved and would learn from each other at the same time and that anyone can present suggestions and ideas for improvement, not just editor to writer. Code review would also reinforce a sense of collaboration amongst the team.
Work, work, dance
Like many programmers, many journalists work a lot. For that time to be most productive, an environment based on embracing failure would support openness, transparency, and collaboration. Structured planning, detailed and well-documented implementation, and space for review and community-building will help us work better, more comfortably, and return the humanity to our workplace where we can share concerns and successes.
It's frustrating to fail. But, once something--a programming script, a lede, an infographic--you've been banging on forever actually works, it's time to dance!