07 Business Agility, The Driving Force Behind Rapid DevOps Implementation #

Hello, I’m Shi Xuefeng. Today, I want to share with you the topic of business agility. So, let’s first discuss what business agility is and why it is needed.

Imagine this scenario: your company has formed a special team to validate the feasibility of a DevOps implementation project within three months. When it comes time to report this to the CEO, as the team leader, you start to worry about how to align the value of DevOps with the business value to demonstrate its impact and contribution to the business.

If you think in this direction, it is easy to get stuck. There has never been any objective evidence to suggest that improving software delivery efficiency directly correlates with an increase in a company’s stock price. In other words, improving software delivery efficiency does not directly impact the business value.

In reality, software delivery teams have been striving to improve delivery efficiency through various means. However, if your assumption is that the requirements are reliable and effective, you may be disappointed. The fact is that business requirements are constantly evolving through trial and error. With the mentality of “it’s better to kill a thousand by mistake than to let one go,” all kinds of wild requirements overwhelm the software delivery team, wasting valuable development resources in the vast ocean of business demands. However, how much value these business demands actually bring is rarely clear.

The longer DevOps is implemented in an enterprise, the more it is realized that while communication barriers exist between development, testing, and operations teams, the gap between the business and IT departments can sometimes be even more significant. How many business departments are satisfied with the delivery efficiency of the IT department, and how many IT teams do not blame the business departments? In short, if the business is not agile, no matter how hard IT tries, it will be in vain! Therefore, I think it is necessary to discuss the topic of requirements with you.

Going back to the original question, if DevOps cannot directly improve the business value of a company, why implement DevOps at all? In fact, if you break down the value of DevOps into two parts: business value and delivery capability, it becomes easier to understand.

In today’s ever-changing era, no one can accurately predict the value of requirements. Therefore, improving delivery capability can help the business to iterate and experiment at the lowest cost, delivering new features to users quickly. At the same time, user and market feedback can be quickly fed back to the business, helping them adjust their direction. The agility of the business is reflected in the ability to design features and grasp requirements. If the requirements cannot be adjusted flexibly and the focus is not on the most valuable things, it will also hinder delivery capability and result in a decrease in overall efficiency.

In other words, in this fast-paced iterative delivery mode, both business agility and delivery capability are indispensable.

Therefore, developing fewer features, focusing on user value, and continuously validating quickly become the core principles of product requirements management.

Developing fewer features #

Many times, the biggest problem faced by teams is having too many requirements. However, in reality, many of these requirements are not well thought out from the beginning, and even during the design and development stages, they continue to change, which greatly troubles the delivery team. Therefore, under the premise of ensuring the quality of requirements, the key issue is how to minimize the delivery batches of requirements and adopt the smallest implementation plan, in order to ensure that high-priority requirements can be delivered quickly, thereby improving the frequency of online experiments and feedback.

Regarding requirements analysis, a commonly used method is the Impact Mapping.

Impact Mapping is a mapping relationship between business goals and product features achieved through a simple “Why-Who-How-What” analysis method.

• Why represents the goal, which can be a core business goal or an actual user need.
• Who represents the affected parties, that is, who is affected in order to achieve this goal.
• How represents the impact, that is, how to influence users to achieve our goals.
• What represents what kind of features need to be delivered to achieve the desired impact.

If you are encountering Impact Mapping for the first time, it may sound a bit confusing. Don’t worry, let me give you an example to help you understand this analytical method.

For example, a column hopes to attract 10,000 users within 3 months of going online. In this case, this “Why” is the core business goal. Who needs to be influenced in order to achieve this goal? It includes the authors, the platform provider, the channel provider, and the end users. What kind of impact should be exerted on them? For authors, they need to quickly answer user questions and improve the quality of content; for the platform, they need to give key exposure to the column and increase marketing activities; for the channel provider, they need to increase promotion efforts and channel traffic; and for users, increase activities such as sharing rewards, free trial reading, and personal points.

Based on these impact methods, the final practical requirements form a complete impact map, as shown in the following figure:

You may wonder, how should the priorities of so many requirements be arranged? Don’t worry, let me introduce you to the “Kano Model”.

The Kano Model is a set of requirement analysis methods proposed by Dr. Noriaki Kano, a Japanese master. It has profound insights into understanding user needs, classifying and prioritizing them.

The Kano Model divides product requirements into five types:

1. Excitement: Refers to the needs that exceed user expectations and are difficult to obtain. For example, users want a better feature phone, and Steve Jobs brought the iPhone, which brings great satisfaction to users.
2. Performance: The user satisfaction of this type of requirement will increase linearly as the number of such requirements increases. The more you do, the better the effect, but it is difficult to make a qualitative breakthrough. For example, an e-commerce platform that initially sold books gradually expanded to sell computers, home supplies, and other categories. The satisfaction naturally increases as more linear demands are met.
3. Basic: These are the essential features that the product must have. If they are not available, it will have a significant impact. However, having these features will not make users praise how well you have done. Examples include security mechanisms and risk control mechanisms.
4. Indifferent: Doing or not doing it makes no difference. This is a typical useless effort. For example, you put a lot of effort into a requirement, but almost no users use it. This requirement belongs to the indifferent type.
5. Reverse: These are non-existent needs that users do not really have the conditions or desire to use. After these requirements are implemented, they usually bring great troubles to users and become the objects of complaints.

For the five types of requirements, the key is to:

• Prioritize the planning of Performance and Basic requirements, and incorporate them into the daily delivery iteration to maintain a certain delivery rhythm.
• Identify Indifferent and Reverse requirements, as these do not generate value for users. If there is controversy in the team regarding the classification of requirements, further user research and analysis can be conducted.
• Pursue Excitement requirements, as they will bring competitive barriers and differentiation to the product. However, for large companies, they often face the dilemma of innovators, that is, they adhere to the existing business model and find it difficult to truly devote resources to innovation and self-disruption. In this case, the Lean Startup mindset should be adopted, using the concept of Minimum Viable Product (MVP) for rapid validation and reducing the cost of trial and error in order to seize new opportunities.

When facing a large number of business requirements, the first step is to identify and classify them. Of course, initially, everyone believes that their requirements are Performance or even Excitement requirements, which can be understood. After all, it’s like all the defect issues in the company are of the highest level because if you don’t mention the highest level, they will be flooded by other highest-level problems and not be resolved in the long run. The solution here is to let the data speak and establish a feedback mechanism for the value of requirements, which is user value.

Focusing on User Value #

“Start with the end in mind” is a phrase that often appears in topics such as Lean and DevOps improvements. In simple terms, it means “hit the target, not just wherever.” Product developers often ask, “Why don’t users use this great feature?” This is a typical problem when looking at things from a product perspective, claiming “the user is God” but actually looking at specific issues from a god’s perspective.

If your company is also undergoing an agile transformation, you may have heard of the concept of user stories. Requirements are not requirements, but stories, which many people find difficult to understand. So, is a user story just a disguised requirement?

Regarding this question, I once asked a senior agile practitioner in China, and his words were memorable. He said, at first glance, a user story is a form of describing requirements using stories, but in fact, it is an important means of business agility. It changes not only the way requirements are written but also the way a consensus is reached on those requirements. In other words, if the so-called agile transformation does not break down the requirements, change the way a consensus is reached on those requirements, and clarify the value of those requirements, then it may just be doing iterative development without much agility.

In the past, there were often two extremes in requirement discussions: one is a one-sentence requirement, a typical “I give you a look, understand on your own” approach, where I just need this thing done, and I don’t care about why or how it’s done, you figure it out; the other is diving into implementation details, discussing how the table fields should be designed, how the modules should be divided, and even rolling up the sleeves to write code together with the developers.

Every requirement discussion turns into heated debates, and the consensus reached is based on compromise, which clearly does not contribute to the harmonious development of the team. More importantly, by always focusing on the functional aspects without considering the user’s perspective, it is difficult to meet the expected deliverables.

On the other hand, user stories revolve around the value to the user, defining a role and indicating what activity will ultimately achieve what value. When the team discusses requirements, they use a storytelling format, immerse themselves in the user scenarios, follow the user’s path of operation, and ultimately achieve the user’s goals and solve their actual problems. The benefits of doing this are that through collaborative discussions and communications within the team, the product, development, and testing teams can reach a consensus on the goals of the requirements, especially the value they want to bring to the users.

In this process, the team continuously explores better implementation solutions and paths and supplements related user stories, thus forming a complete backlog. What’s more important is that team members gradually develop user and product thinking, no longer bound by technical implementation itself, strengthen trust among each other, and improve their initiative, thereby enhancing the team’s agility.

The granularity of user stories also needs to be divided. The principle of division is to deliver a complete user value for a given user role, which means user stories cannot be further divided. Of course, in practical work, the granularity of division should still be based on the iteration cycle, completing the delivery within one iteration cycle, generally recommended to be 3-5 days. To determine whether the granularity of user story splitting is appropriate, the INVEST principle can be followed.

So, what is the INVEST principle?

• Independent: Reduce dependencies between user stories to allow more flexible verification and delivery of user stories, which is crucial for business agility and to avoid massive delivery.
• Negotiable: User stories should not be implemented strictly like administrative orders, but rather present a scenario description and gradually refine it during the requirement communication phase.
• Valuable: User stories are centered around user value, so each story is delivering value to the user. Therefore, thinking from the user’s perspective and avoiding statements like “I don’t care what you think, I care about what I think” is important.
• Estimable: User stories should be able to roughly estimate the workload, whether in story points or time. If it is a story of exploratory nature, further feasibility needs to be dug into to avoid doing something without knowing why.
• Small: User stories should be the smallest unit of delivery. Therefore, according to agile development methods, whether it is an iteration or a kanban, it needs to be completed within one delivery cycle.
• Testable: This refers to acceptance criteria. If there is no way to prove that the requirement has been met, there is no way to accept and deliver it.

Continuous Rapid Validation #

The concept of user value may seem somewhat elusive. Indeed, just as we cannot predict the future, the value of a requirement is difficult to predict. However, the value of a requirement can still be defined. Therefore, the definition of requirement value can be understood as the measurement of requirement value, divided into objective and subjective aspects.

• Objective indicators: These are indicators that can be demonstrated by objective data. For example, in the e-commerce industry, indicators such as the arrival rate of goods, the rate of reaching product details, the rate of adding items to the shopping cart, and the rate of completing orders can be identified from the perspective of the purchasing process.
• Subjective indicators: These include user experience, user satisfaction, user recommendation rate, etc. They cannot be directly measured and can only be inferred through associated data.

Regardless of whether it is objective or subjective indicators, each requirement can select its expected performance in these indicators when it is proposed and define corresponding metrics. On one hand, this strengthens the value orientation, delivering requirements that have greater value. On the other hand, it emphasizes data orientation, aiming to objectively present actual results as much as possible.

Of course, product requirements are a complex system and can have mutual influence and dependencies. How to identify key indicators from multiple metrics and associate them with the requirements themselves is a discipline in itself. However, don’t worry, I will discuss this with you in detail when it comes to measuring related content.

In many enterprises, the MVP (Minimum Viable Product) mindset of lean entrepreneurship has become deeply ingrained. Faced with an unknown market environment and user demands, in order to quickly validate an idea, a minimal product implementation can be used to obtain real market feedback. Based on the feedback data, the product goals and requirement priorities can be adjusted, thus continuously iterating the product requirements.

This mindset is generally applicable, but in practice, it may deviate. For example, when a requirement is proposed, a set of predefined metrics are established. However, after the product is launched, due to a lack of data support, the evaluation of requirement value becomes purely subjective, with the business department independently determining whether the requirement has met expectations, is in line with expectations, or has not met expectations. As a result, almost all results are likely to indicate that the expectations have been met or exceeded. But the question is, does this kind of derived result truly help the product direction?

Therefore, adopting an objective and effective feedback mechanism becomes a must. From a technical perspective, behind a business requirement, there is usually a need for data tracking. The so-called tracking analysis is a commonly used data collection method for website analysis. Well-designed tracking functionality not only helps collect user behavior data, but also recognizes complete context, operation pathways, and can even perform clustering and analysis of user profiles to identify the behavioral habits of different types of users. From a user perspective, crowdtesting mechanisms and user feedback channels are common methods, with the core principle being to listen to what users say and observe what users do.

Summary #

The focus of DevOps should continue to extend from the development process and include the business team. This means that the IT department should not only passively deliver functionality according to business needs, but also provide business data feedback faster and assist in business decision-making. At the same time, the improvement of delivery capability further reduces the cost of business trial and error, and the agility of the business determines the value and delivery rhythm of development delivery. By analyzing requirements through impact mapping, analyzing requirement attributes and priorities through the Kano model, reaching consensus through user stories and the entire team, and continuously and rapidly verifying, it helps the product develop and progress on the right path.

Introducing business into DevOps becomes BizDevOps, which is also a trend in the development of DevOps. Finally, let me summarize the core principles of BizDevOps for you:

• Align business and development goals and metrics;
• Grasp security and compliance metrics;
• Timely alignment of requirements to reduce unnecessary development;
• Demonstrate the value of DevOps;
• Enable the development team to engage with the business, not just execute tasks, to stimulate enthusiasm.

Thought Questions #

How is the value of demand measured in your company? Is there a set of indicators that can objectively demonstrate the value of demand?

Welcome to write down your thoughts and answers in the comments section. Let’s discuss and learn together. If you think this article is helpful to you, please feel free to share it with your friends.