DesOps is "DevOps 2.0"

As we discussed in the last post, most of DevOps today focuses on the process blocks that mostly impact engineering or technical aspects of a product rather than the design aspect. Even though  DesOps was primarily born out of the primary need of how to design at scale, the factors that shaped it are of a similar nature to the factors that shaped DevOps.

With recent software delivery processes, for example, the Agile process and Continuous Integration (CI) and Continuous Deployment (CD)of code, the DevOps approach provided a faster highway to ensure faster delivery with low risks. So the earlier SDLC model got redefined over time with Agile and then with DevOps to its current shape.

However, because design is an integral part of any product delivered, there is a need to ensure that gaps are bridged between the traditional design lifecycle and the fast track of the DevOps development lifecycle. DesOps and DevOps both are complementary to each other. The design delivery process improvements try to optimize the overall delivery process and thereby contribute to DevOps, for example, in aspects such as testing of the product that involves design aspects, usability, accessibility, etc.

The need for tighter integration between the design team and the engineering team became a necessity to ensure to design at scale. During the past two to three years, the top five big companies have made heavy investments in this area that have paved the way for other organizations and design communities to be more explorative in this area.

The implications of DesOps are reflected in the outcome, where the silos among the teams and disciplines get reduced. Along with this, DesOps improves the collaboration among cross-functional teams and work practices, which contributes to minimizing waste in the delivery process.

Every product lifecycle has one core goal towards which it strives: reaching customer delight by delivering the value. The design process associated with DesOps helps in understanding, capturing, and delivering that value.

But conventional business processes were more keen on getting the outputs of each process block, which can be fed into the next block, thereby reaching a stage that ultimately delivered the value. Many such practices failed in achieving customer delight because the processes used were not based on the customer shift from outputs to outcomes.

If we see the DesOps processes in terms of a value system, we will see at a high level that DesOps touches upon three major areas:

1. Understanding value
2. Creating value
3. Capturing and delivering value

As discussed in the last post, in the value system approach, understanding value is about reaching a vision. Creating value is broadly about reaching a roadmap with Minimum Viable Product (MVP). Capturing and delivery value is about running the backlog and sprints and ensuring delivery until the end users have access.

Because design is associated with entities and attributes beyond the quantifiable science of connecting with disciplines that are associated with the emotional aspects of the qualitative approach, the implementation of DesOps is more fluid than the case of DevOps.

For instance, if we plot the techniques and practices of any domain according to the left brain–right brain analogy, we can see that most of the practices having soft-attributes or dealing with human emotions, purpose, and behavior will fall into the creative aspect, which involves some kind of design approach to problem-solving.

As one example, you can see in the following figure that the right side shows the mapping of practices involved with software incident reporting. Here you can easily notice the pattern.

The typical belief is that the left side of the brain mostly processes logical thinking, while the right side is more about emotional thinking. Based on this popular analogy, when we map across a straight line from left to right (refer to the previous diagram) the different aspects involved in different stages of SDLC for a digital product, we will notice the logical and more human-centered aspects are divided by an imaginary line from the center. We will also notice the gradual progression of the emotional index for the components from left to right. This helps to demonstrate how the more-human angle is involved as we move from the areas that DevOps touches upon to the areas that DesOps touches, because DesOps touches upon the design and business aspects of the value chain.

From foundational guidelines, DevOps inspires the DesOps mindset at a high level:

1. Partnering with customers for improving business value
2. Working together towards a shared vision
3. Delivering incremental value
4. Investing in quality
5.  Empowering team members
6. Setting up clear accountability in teams
7. Learning from experiences
8.  Advocating open communications and transparency
9. Being agile and adapting to change

In such a context, if we look into DesOps, it makes a lot of sense in the following key principles:

1. Implement DesOps to follow service design methodologies.
2. The feedback loop should cut across the product lifecycle.
3. Empower stakeholders for better decision-making—hypothesis and data-driven decision-making for design and development.
4. Empower design thinking.
5. Advocate lean methodologies and Agile philosophies.
6. Translate user-centered design into an actual process that can be used on the ground.
7. Advocate cohesive designers, stakeholders, and developers into team play.
8. Technology decisions should be guided by lowering the boundaries between roles and automation to reduce waste and reduce repetitive jobs to work for the product and the project.
9. Redesign and re-engineer the processes.
10. Enable reviews based on data-driven benchmarks.

So how does this all fit in? At a crude level, the DesOps processes may have something like the following structure when they are translated in terms of technology and ecosystems, in a similar fashion as DevOps.

1. First, we should create the design benchmarks (that includes qualitative as well as quantitative metrics) from the information at the design stage that can be used in comparing the product features against metrics based on this design benchmark.
2. Then, automate and perform manual tracking of the product during runtime (in real time and in the true context), and then categorize and collate this data.
3. This involves creating features to support the user feedback cycle and user testing aspects (exploratory, split testing capabilities).
4. Collect all standards and specifications on different aspects of heuristics to ensure that at least at the basic level the standard principles are followed.
5. On the ground, in the context of the eco-system and technologies, build the critical components that would collect and process all the data collected in all these stages and generate the desired metrics and inferences and also contribute in bringing continuous integration and continuous delivery blocks to run the process.
6. Build the unit to generate the model to map the data and compare it against the metrics.
7. Build the cognitive unit that can compare the data and apply the correct models and metrics to carry out the filtering of the data and generate the insights which can be shared as actionable output to the end-user/customer.
8. And ensure in all these stages that the feedback loop is connected spatially and acting as a meaningful neural network that helps in informed decision-making.

Keep tuned in to stay with me on this journey into DesOps!

(Note: Based on my book The DesOps Enterprise: Overview & Culture)