Figure: Linking various aspects for an article that can be connected through the “DevOps way of working”
Innovation lies at the intersection of two or more otherwise-non-related areas. A very intriguing such instance I recently read was of Charles Babbage and Ada Lovelace setting up the foundation of the modern programmable computer by taking the punch card from the loom industry and applying it to their analytical machine (see: Wikipedia or refer to the book, “The Innovators“). There have been numerous cases where one industry has taken up the best practices of another industry and aligned it to work well in a new use case. We don’t have to go far to look at such examples; the IT industry has picked up a lot of manufacturing industry best practices such lean and Kanban.
Today a lot is being talked about DevOps in the IT world as the new model of software development and support. The DevOps way is being adopted by various teams and everybody is exploring how they can adopt it in their environment. Can we break down the “DevOps way” and extend its principles to some other areas of work?
DevOps in its simplest definition serves one purpose: Enabling businesses to reach their consumers faster with innovations and new offerings, enabled by tools and automation. By incorporating lean principles, automating various steps and bringing all the stakeholders closer (biz-dev-test-sec-ops), the life cycle is aligned to release continuously. The main objective is to have a releasable version always ready to be pulled, rather than wait for long periods before the next increment is available. That way, releasing it for the end users becomes a simple business call and a non-event.
How can we extend the DevOps principles to the benefit of other business functions?
What is the natural process that comes to the mind for completing an assignment? Does it look some variety of the below figure?
Figure: Generally followed process model for completing an assignment from start to complete. There might be one or two iterations of the output, that means feedback provided once or twice. Low collaboration between stakeholders results in sub-optimal output or significant rework and wastage.
Some shortcomings in the above process are:
- There are no defined interim timelines or, even if defined, are not tracked among other competing priorities
- Feedback is received only once or twice in the whole cycle
- Approving sub-par quality output to close in time
- Results in a high cost of change because feedback is received on near the complete version
- Generated artifacts are not maintained properly, thus reinventing the wheel every time
Accommodating slight changes in the above process can offer significant improvements overall. The first step is to make the “outcome” at the center of all the other things (instead of “output”). By keeping the end result (outcome) at the center and aligning all other things around it, we ensure that the objective is clear.
Figure: Suggested process flow model keeping outcome at the center and completing the assignment iteratively and continuously. Output can be picked up when all the stakeholders are satisfied. This model gives an opportunity to start socializing a work-in-progress version and get continuous feedback.
What I am saying here effectively is that we put the entire focus on the outcome and make the process “iterative” and “continuous.” “Iterative” essentially means that you don’t aim to complete the work in near entirety before going for a review. You break down the task into logical steps which will incrementally show the reviewer the direction or approach you are taking toward the task completion. And continuous refers to the lean flow, enabling the outcome to not get stuck at any stage, and continuously being aware of and removing bottlenecks.
Make every important outcome a time-boxed event and work toward its closure in an agile manner. One of the best ways to complete something proactive is by creating self-imposed deadlines. Agile (or scrum, specifically) provides a systematic way of putting deadlines in the whole life cycle (McKinsey Article – “Making your marketing organization agile: a step-by-step guide“).
My belief is that the same concepts can be extended to any important assignment for effecting the outcome.
Figure: Agile Scrum process which suggests maintaining the requirements in a backlog that is always kept prioritized. Then work in an iterative manner, generating output incrementally toward an ever-improving state, incorporating feedback continuously.
The key thing to observe here is that sprint duration and ceremony frequency can be adjusted to make them much more frequent than the recommended one to four weeks.
Some people consider agile-scrum unnecessary. Well, the concept of Minimum Viable Product (MVP) and creating a “continuous” flow in the development of work item can be brought in irrespective of whether a team follows an agile-scrum approach or not. I have drawn that parallel and created a universal model for any kind of artifact (non-code – such as marketing flyer, legal contracts, product documentation, customer presentations, reports etc.).
Figure: A model for following the DevOps best practices of continuous feedback, collaboration, automation and continuously improving outcome in any type of work environment or team.
Here the requirements can come from any source internal or external to the organization. The “source content management” should become the single source of truth for any final artifact; it will also be the versioning system to maintain a record of historic artifacts. The orchestration platform could be an advanced CMS tools, a utility application developed in-house or a simple cloud storage tool such as OneDrive, Google Drive, Dropbox or even plain file systems.
There will have to be a set of process and policies that support this model. I have appended an indicative list below.
Collaboration sits at the core of the entire model. Unless people come together and share continuous feedback, the DevOps way of working cannot succeed. The lifecycle stages are explained in the next section, but the main idea is to prototype fast, get continuous feedback, fail fast and always maintain a releasable version ready. Feedback should become an integral part of the entire system. Feedback captured internally or from external audience should be captured and stored along with the artifact version for which the feedback was received. The next time the iteration starts, because the artifact is a periodically updating work item (marketing campaign or sales pitch material) or is being enhanced (website content or product documentation), the latest artifact version along with its feedback should be taken into consideration.
The lifecycle stages for good-to-have artifacts are presented below. These stages could be slightly different than the one indicated in the above model to suite your requirements:
- Dev (Development environment): Individual contributors local machine. People work on their picked stories (as in agile: a broken down unit of work). This could be an individual or a group of people.
- Int (Integration environment): All the individual pieces are stitched together to form one coherent outcome. There should be an artifact ‘owner’ (as in agile: product owner) identified, who will do this work on his system. This has scope for automation. It will benefit if done collaboratively.
- Test (Testing environment): Receive review and feedback by the approver (could be the “owner” or business leader who gave original requirements). This stage has a scope for automation. From this stage onward, the content resides centrally on the source content management system.
- Pre-Prod (Pre-production environment): Approved and finalized version rests here until sent for final audience’s use.
- Prod (Production environment): Only those artifacts that are for end users are maintained here (published news item, signed contracts, delivered customer pitch, etc.). Maintain the version-controlled artifact. This stage also becomes the single source of truth for all artifacts. Maintain historic data for record-keeping. Market feedback is captured and stored along with each version.
- Release & Ops Mgmt (Operations): The purpose of this stage is to ensuring periodic cleanup activities in the source content management system. Ensure periodic enhancements on the content and maintenance of production copies.
Artifact lifecycle policies, to start. You may identify and add more as per your requirements:
- Identify owner for each artifact. She would become approving authority for the content.
- Prototype & fail fast (MVP). Follow agile methodologies as much as possible and adjust sprint duration for different content types.
- Make feedback your bible. This is necessary for continuous improvement. Record the feedback and act on it.
- Collaboration should be at the heart of the entire process. All involved individuals should be part of the entire artifact life cycle.
- No e-mail content should ever be accepted for review, approval or final use. E-mail can be sent with a link for source content management.
The purpose of this article was to draw a parallel with non-code artifacts so that DevOps philosophy can be understood with a non-development angle. It’s my hope that it is evident that DevOps is not something that can be adopted overnight, and it’s not just about implementing tools. People have to be aligned and trained for the new ways of working. It entails a lot of cultural change to be initiated. And finally, the benefits are better visible as the scale grows; however, small steps must be taken at the beginning to identify a model that is fit for your specific landscape.
This is the first iteration of this article and it will surely undergo improvements. Feedback and ideas are welcome in comments below.
About the Author / Kunal Gupta
Kunal Gupta is Product Owner in IG Group for their Payments team. Prior to this Kunal managed AgileBase, a DevOps platform developed in and by Wipro, a global IT major. Kunal played a key role in defining and streamlining the roadmap for AgileBase platform, its pricing and positioning to global customers. Kunal has diverse experience in Technology Product and Services Industry spanning across Product Management, Presales, Sales, Campaign Management and Demand Generation. He has a worked for major customers in financial, technology, and manufacturing industry across U.S. and European markets. Connect with him on LinkedIn.