You’re an Instructional Designer or another flavor of content creator. You’ve attended a few meetings recently, big meetings that all the “technical folks” and your authoring team have been a part of. The topic was “DevOps” as a practice, how it’s going to speed up your ability to produce content, and allow your team to release your product more frequently. The ideas sound exciting, and you’re on board, so long as your content gets in front of your target audience with the intended impact.
You want to make sure you’re doing it right. You’ve just gotten off of a very informative meeting with the technical architect and the lead designer. They walked you and your team through the various workflows of loading your content into your content management system. They called out various caveats you might bump up against, and highlighted a number of very helpful tips and tricks that’ll really make your content pop. You feel empowered, and pretty excited to get going on the work. You have some tight deadlines after all, but the work seems doable given what you just saw from the development team.
Within a week, and with much trial, error, and “can you fix this?” conversations with the development team, you’ve completed the first draft of your content integration into the system. The QA team is pouring over your work, and initial reports look promising. Within a month, it’s announced that your product is going live in production. As the public-facing product shows up on your screen, you admire your work. You receive and pass along congratulations with your team. Glancing over at your huge list of notes containing step-by-step instructions, various HTML and CSS snippets, and links to documentation, you’re impressed with how much you learned in just a short month, and especially with what you were able to achieve in such a short timeframe.
You feel confident that the next time around, this work will go much smoother and faster. Still, the “DevOps” buzzword is rolling around in the front of your mind. You google it for fun. Then, it clicks: DevOps is the reason you got your product out so quickly, and also the reason you know so much about HTML and CSS now!
Understanding DevOps
DevOps, at its simplest, is the combination of Development and Operations. In recent years however, DevOps has become more of a set of guiding principles, with the goal of taking software from proof-of-concept to production-ready as quickly as possible, without sacrificing quality. In historical software development practices, Operations, Development, and Content Creation teams often had little to do with one another, and getting answers for solving your task at hand could take days, and consequently extend release timelines. DevOps Methodologies attempt to remove those knowledge barriers, shorten the timelines, and combine teams’ activities to rapidly achieve their common goal.
DevOps Principles in Practice
When attempting to truly understand and incorporate the DevOps principles into your software creation practices, it’s easy enough to boil it all down into mantras like “Teamwork makes the Dream Work.” Let’s take a look at the overarching principles in DevOps and see how they fit in.
Foster a culture of collaboration
Invite thoughts, opinions, and feedback on everything. Ensure that all participants have a voice, and that their feedback and concerns are heard and addressed. Encourage feedback, and provide proper channels to provide that feedback in a way that it can be discussed and considered.
Assign end-to-end responsibility
Everyone on the team at large has a role to play. Ensure that every team member knows what they are responsible for, and takes ownership of those activities.
Encourage continual improvements
As a team, decide what your Minimum Viable Product (MVP) is, but don’t stop there. Keep ideas flowing and brainstorm on what future enhancements could be made. This can be the product itself, workflow refinements, addition or removal of a tool in the process, or whatever else might be a value-add for the team toward the end goal.
Automate wherever possible
DevOps attempts to do away with the overhead of manual steps, where a person is responsible for handling repeated tasks. Instead, DevOps automates where possible, removing the need to rely on a person to do the job that a computer can more readily handle.
Focus on your target audience
The end user ultimately dictates the work a DevOps team is producing. Often, DevOps teams ask themselves: “Does this feature serve the needs of and enhance the experience of our users?” The answer to that can help to quickly determine the direction of any effort.
Fail often and learn from your failures
No one wants to “fail” in the general sense, but in DevOps, it’s a vital step toward approach and discovery. In order to see what’s going to work best, a process of trial and error is often required. DevOps encourages team members to try new things, and learn from failed attempts at what’s not going to work. Once something does work, the result is usually the proof of concept that can be iterated on toward MVP.
One Team, One Goal
In DevOps, the concept of “separate teams” doesn’t exist. Instead, DevOps teams are structured and aligned on a unified goal, and team members take responsibility for their practice areas. With the “One Team” mentality, members feel more encouraged to reach out to one another, and work together to achieve their overarching goal.
DevOps Principles in Content Creation & Delivery
Content Delivery
Often, instructional designers and content authors are limited by the tools and software that display their content. Take any learning management system for example: often the author can only add simple text content and images by themselves, limited by a slim list of layout and placement options. Often, they may have to seek consultation from a learning experience designer to learn some fancy tricks with CSS and HTML, or ask a developer to add a much desired feature in order to get close to their grand vision for their content.
In the DevOps world however, the ID/CA would have early access to the software, and explain the need for the feature to a developer. By the time the content is prepared, the functionality to achieve the author’s intended vision already exists, has been tested, and is ready for use.
Authoring Tools
Proper tooling for an author starts with the development team assessing how the content creators like to work. Authoring workflows might be managed in Word or Google Docs, or any number of authoring platforms that exist out in the wild. It doesn’t much matter where or how the content is generated, so long as the content can be consumed within the DevOps process. MS Word docs can be transformed into HTML, Google Docs & Sheets offer APIs for reading data, as do any major CMS/LMS and repository hosting services like Github and BitBucket.
A savvy development team can then analyze what they’ve learned about how the authors like to work, and begin to develop strategies for aligning technologies and workflows that complement and enhance the authoring processes.
Since the team at large is already meeting frequently to brainstorm and discuss potential solutions, the developers present their ideas and proof-of-concepts to the authors. Lots of “Here’s what we’re thinking” and “What about trying it this way” and “That might not scale, but it’ll get us by for now” statements arise, but overall, developers seem pleased that authoring isn’t blocked, and the authors are pleased to have early access, insight, and input into the development process.
Delivering Quality Content Faster
Automation
Authors like what they are seeing from the developers, and are excited to get their hands on the new features. The next day, you see a post in your team chat from the developers announcing that when your content changes are made, they are automatically deployed and available for review on your development site. This is great! You no longer have to wait around for the developers to get your changes out there. You can do it all yourself!
From a DevOps perspective, automation is the second most useful principle. With the tight coupling of Development and Operations working together, and with the goal of increasing the frequency of software updates, the solution is automation, and the results are drastically shorter turnaround times from concept to availability. A shared mantra between both Development and Operations is “If any part of the software and content lifecycle can be scripted against, it can then be automated.”
Communication
Communication is without a doubt the most useful principal in DevOps. Without established communication channels, frequent discovery and brainstorming sessions, and processes to provide and integrate feedback, software and content creation lifecycles and timelines suffer greatly. Chat tools like WebEx Teams are invaluable, with lots of integrations for notifications on automated events, and a plethora of external tools. In the name of “One Team, One Goal,” a DevOps team should consider including scrum ceremonies like demo and planning meetings, which offer the opportunity for more immediate feedback to be heard and considered.
With the goal of streamlining efficiency in execution, all team members need access to one another. Within DevOps, gone are the days where a team member is required to create a ticket or sit on hold with a help desk in order to get their needs in a queue for completion. Relaying and obtaining critical information should be immediate (or close to it, we’re all human), going through as few channels as possible. This puts the onus on individual team members to both manage issue priority and be respectful of everyone else's time.
Picture communication as the oil for a machine: add it to the parts of the systems that need it to keep things running smooth and efficiently.
DevOps Culture
DevOps extends past a prescribed list of principals, as much as it extends past the simple Development and Operations combination. DevOps is a philosophical embodiment of all the concepts that, when practiced, facilitate making a team of people successful at delivering their work, affording process refinement and enhancement along the way. DevOps is a culture, and like all cultures, it is defined by the relationships of the people that participate within it.
DevOps, as a culture, encourages and invites these relationships. It incentivizes building relationships into partnerships. To be successful as a practice, DevOps culture gently nudges its community to learn and explore areas outside any individual’s comfort zone, and empowers them to turn to their team members and ask with confidence: How can I help?
