History of agile development
The practice of agile software development first appeared in the 1990s. At that time, a group of lightweight software engineering methods and frameworks emerged. Unlike traditional software engineering, they all followed an evolutionary and iterative model. Their processes were more lightweight and flexible. Among them, Scrum and Extreme Programming (XP) were the most successful and influential in practice. Both are iterative and incremental software development frameworks. The main difference is that Scrum includes only management practices, while XP covers both engineering and management practices.
In February 2001, 17 representatives of lightweight software engineering methods met in the United States. They published the influential Agile Manifesto (http://agilemanifesto.org/). The manifesto outlined their shared beliefs about software development methods. Just as importantly, they chose the word "agile" to represent these ideas.
After the Agile Manifesto was published, agile became a movement that was quickly promoted and widely adopted. Agile focuses on the development and delivery phase. From a business perspective, the goal of agile is to help product and development teams improve their ability to respond to change. This means delivering value earlier and responding to change more flexibly.
The 12 principles of agile development
The 12 principles of the Agile Manifesto have been applied to manage many business and IT-related projects, including business intelligence (BI). The 12 principles are:
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Business people and developers must work together daily throughout the project.
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
Face-to-face conversation is the most effective and efficient way to communicate.
Working software is the primary measure of progress.
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Continuous attention to technical excellence and good design enhances agility.
Simplicity—the art of maximizing the amount of work not done—is essential.
The best architectures, requirements, and designs emerge from self-organizing teams.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
At the tool level, Apsara DevOps helps enterprises implement principles 1, 3, and 8.
The 3 inequalities of agile development
To improve development efficiency with agile development, you must first clarify the problem you are trying to solve. Then, you can implement the practices to solve it. Without a clear problem definition, good results are difficult to achieve.
So, what problems must be solved to implement agile development and improve efficiency? He Mian, author of Lean Product Development, summarizes these problems as the 3 efficiency inequalities.
First inequality: Local efficiency does not equal efficient delivery.
This may sound familiar. When you ask individual departments or team members, they all say they are busy and efficient. However, when you ask business departments or users, you hear a different story. They complain about slow product development responses, late deliveries, and poor quality.
This is because local efficiency from an internal perspective does not equal efficient delivery from a user's perspective. This is the primary problem to address when improving development efficiency. Solving this problem requires more effective organizational collaboration, a more reasonable delivery model, and better process quality.
The next question is, is efficient delivery enough? This leads to the second efficiency inequality.
Second inequality: Efficient delivery does not equal sustained high efficiency.
Sometimes, to achieve efficient delivery, teams might take temporary measures. For example, a team might be assembled for a temporary project to make communication and collaboration easier. This might achieve temporary high efficiency. However, without a long-term quality mindset, problems often arise in the next project. The code and design from the previous project have issues, such as being difficult to modify and reuse. They become liabilities instead of assets for future projects, and long-term efficiency cannot be maintained.
Transforming efficient delivery into sustained high efficiency is the second problem to solve. This requires strong engineering capabilities, technical skills, and sound practices.
Third inequality: Efficient delivery does not equal business success.
The purpose of product delivery is to support business development and innovation. We must ensure that what we deliver solves user problems and builds a sustainable business model. Otherwise, delivering more products or features is meaningless.
We believe that the essence of improving development efficiency is to resolve these three inequalities. This process transforms local, internal efficiency into efficient delivery that users can perceive. It also ensures sustained high efficiency and contributes to business success. The ultimate goal is to achieve smooth, high-quality, and continuous delivery of effective value. This is the fundamental goal of efficiency improvement.
Implementing agile development requires the participation of core roles within an enterprise. Using the three core roles of product, development, and testing as examples, we will explain how they can promote and support the implementation of agile development.
Next, we will explain step-by-step how business, product, and technology teams can implement agile development and progress towards the continuous delivery of useful value.
Responsible role | Goal | Managed objects | Responsibilities | Workspace and items | Workflow (This is a reference and can be customized by the enterprise) | Data measures (This is a reference and can be customized by the enterprise) | |
Business layer | Business team | Respond to and meet business demands to achieve business goals Meet your business goals | Focus on business requirements while also tracking their associated product requirements | Business team:
Product team:
| Business workspace Use the Apsara DevOps "Business Feedback Management Workspace"
| Proposed - Accepted - Analyzed - Planned - In Progress - Pending Acceptance - Accepted (Satisfaction) - Published | Measure delivery process Requirement delivery rate On-time requirement delivery rate Requirement delivery satisfaction Measure resource investment View R&D resource investment from a business perspective View the proportion of business requirement sources from an R&D perspective Note: Measures for original requests and subjects will be available soon. |
Product layer | Product delivery team (includes product managers and technical teams) | Planning and fulfilling product requirements Meet business delivery needs, both short-term and long-term | Focus on product requirements while also tracking their associated technical tasks | Product team:
| Product delivery workspace Use the Apsara DevOps "Product Planning Workspace"
| To Be Scheduled - Scheduled - In Development - To Be Tested - Completed | |
Technology layer | Technical development | Complete technical tasks and deliver requirements in a timely, high-quality manner | System changes and other personal tasks | Product team:
Technical R&D team:
| Technology delivery workspace Use the Apsara DevOps "Scrum Agile Delivery Workspace"
| To Do - In Progress - Done | |
Test developer | Complete testing tasks to ensure high-quality delivery | Test cases and bugs | Test R&D team:
| Bug delivery workspace
| To Be Confirmed - Confirmed - Fixing - Fixed | ||
Overall goal | Connect the end-to-end delivery process, ensure process quality, and align work across all layers. The final goal is to achieve smooth, high-quality delivery of business requirements. | ||||||
Agile development process and scenarios
So how is this implemented in practice? Next, we will take a deep dive into the agile development implementation process. We will use Scrum as an example to introduce the agile development process and its scenarios, as shown in the figure below:

Overview of the Scrum method for agile development
Next, we will explain in detail how Apsara DevOps helps business professionals, product managers, developers, and test engineers implement agile R&D collaboration.
First, the product manager will:
Collect, research, and analyze requirements to form a prioritized product backlog. For more information, see How Product Managers Can Excel at Requirements Management.
For high-priority requirements, create a low-level design and clarify the details. For more information, see How PMs Design Workflows and Create Kanbans.
Through an iteration planning meeting, form a prioritized iteration backlog. For more information, see How to Excel at Iteration Planning.
After planning is complete, the requirements flow from the product manager to the technical team. For more information, see How Developers Can Manage Bugs Effectively.
With clarified requirements, the R&D team will:
Continuously develop and deliver the contents of the iteration backlog in iteration cycles of 1 to 4 weeks. For more information, see How to Effectively Follow Up on Iterations.
Use a daily stand-up meeting to follow up on plans and identify problems. The team will also continuously or intermittently deliver working software during the iteration. For more information, see How to Excel at Test Case Management.
At the same time, the product manager will design and clarify requirements for the next iteration during this phase.
After the development of the iteration backlog is complete, the product manager and the R&D team conduct an iteration demo together to deliver working software. For more information, see How to Effectively Measure R&D Effectiveness.
Finally, use iteration review metrics to drive continuous team improvement. For more information, see How to Conduct an Effective Iteration Review.
For more use cases, see: