10 points of knowledge learned from the study of Reifer's "quantitative analysis of agile methods"

I. 10 "knowledge points" of the agile approach

Reifer Consulting LLC published a benchmark report entitled "Quantitative analysis of Agile Methodologies 1", which compares the productivity, cost, duration, and quality of agile methodologies with traditional program-driven projects. The report analysed the work data of 800 projects (including 250 agile projects), spanning 10, using the full working data provided by 60 organizations.

The following 10 "knowledge points" can be found in our agile studies, and the results of the study are documented in the benchmark report we refer to. This report is currently priced at 795 U.S. dollars, can be ordered here, click here to learn more about the international Software benchmark organization.

1. Agile productivity-the agile production rate (measured in output/unit input costs) is higher than the experience benchmark for planned-driven projects for delivered products. The benchmark was taken from 10 years of data floating 50% in nominal terms, with the average productivity up to 10% to 20% per cent a year after agile. However, these improvements depend on the area of application and are influenced by a number of factors (such as the labor structure, product complexity, project size, etc.). For example, there are projects that need to be authenticated (such as flight safety and security certification), and these projects do not seem to apply to agile methods. Capers Jones Data 2 confirms our view that such a project uses structured processes such as RUP3 (the Unified Software development process) and TSP4 (Team software processes) to pass certification more quickly.

Drive factor: Improve team work, use lightweight processes, focus on products, executable code, and potential Hawthorne effects.

Problems: development, maintenance or organizational issues, process rigidities and dogmas, overly strict management, outsourcing issues, lack of product management at the core.

Response: We propose the following recommendations for improving agile productivity:

Understand the variables that affect productivity (architecture stability, product complexity, employee skill level and experience, etc.) and deal with these variables when you switch to agile.

Collect productivity measurements and metrics that help us make the necessary adjustments.

It is inevitable that there will be resistance to the reforms, and it is recommended that the pilot project be run to collect metrics and measurements from these projects, and that the data show that agility is a better way of doing business.

Adjust processes and agile methodologies in pilot projects to identify the best way to achieve business goals.

If conditions permit, it is best to have everyone working together to avoid management and contract issues on the first project.

Keep Agile focused on the development of those applications that can bring differentiation.

A single spark can be a prairie fire, and an agile success can bring more success.

2. Agile costs-agile costs (measured in cost/unit output) are less than the empirical benchmark for a planned-driven project. The empirical benchmark range is derived from data that fluctuates by 100% in nominal terms over a 10-year period. An average of 20% to 40% reduction in the cost of a year after agile adoption. Similarly, this cost change depends to a large extent on the area of application and is influenced by many factors, including the structure of labour and wage levels.

Drive factor: Reduce labor cost rate, reduce management cost, simplify communication mechanism, pay more attention to product rather than process.

Problem: More emphasis is placed on development than on avoidance of maintenance costs, reorganization and role clarification, rigid processes, too strict governance, outsourcing issues and the management of products.

Response: We propose the following recommendations to reduce the cost of agile:

Understand the variables that affect costs (these variables are different from productivity) and deal with these variables when switching to agile.

Project estimates based on facts (usually all sprints estimates of deliverables and less than the final product should have deliverables)

Monitor project cost and track budget expenses.

Focus on early investment in agile education and training.

Purchase appropriate tools and set up appropriate operating mechanisms (War Room, task Board, etc.) before work is carried out.

When you switch to agile, you should follow the principles of frugality and simplicity as much as possible.

3. Agile Time-to-market-The agile time-to-market (the overall effective time to measure software from start to end delivery) is 10% to 60% shorter than the empirical benchmark for plan-driven projects, with an average reduction of 20% to 50% after Agile adoption (different project sizes vary). It should be noted, however, that the need to accelerate the delivery cycle often misses some of the requirements, making the delivered features and features not fully responsive to the needs of customers or users, thereby reducing customer satisfaction.

Driver factor: Focus on the artifacts being developed, develop quickly during the sprints period, and deliver the demo version incrementally before the final market.

Problem: Failure to complete all work commitments during the sprints period, the backlog is not clear, customers or users may not be team members, managers may not participate in the agile work.

Response: We propose the following several recommendations to shorten the time to market Agile:

Understand the variables that affect time-to-market and take care of these variables when switching to agile.

Take full account of environmental considerations, develop realistic time estimates for the project as a whole, and then adjust the sprint and incremental plans.

Monitor milestone achievement during project development.

Let the team control the sprint timeline.

Set expectations for incremental timelines and content.

Stick with the artifacts at the end of each increment and try to get customers or users, marketers, and managers to participate.