APD Agile Improvement Case Study of a Distributor Business Unit R&D Team

The Home APD (Agile Product Development) methodology is being practiced in dozens of teams across multiple business units; successful cases are collected and shared. This article presents the APD agile improvement case of a distributor business unit R&D team.

Team status before improvement

The team consisted of 4 product staff, 12 developers, and 1 tester, mainly supporting various marketing activities. The main problems were:

Weekly iteration releases were too slow for the demand side, which wanted faster delivery.

Frequent requirement changes during development.

Developers were bound to fixed business modules, limiting flexibility to respond to multiple product needs.

Stage results after improvement

Starting in August 2017, the team underwent a six‑month improvement process. Key outcomes included:

Iteration frequency changed from weekly to daily releases, meeting the demand side’s need for rapid response.

Demand items were broken down to granularity of less than two days; with clear requirements, change frequency decreased.

Team members transitioned to full‑stack development, enabling developers to handle multiple product demands.

Throughput stabilized at about 240 items per month (≈20 per person), more than double the previous level.

Delivery cycle shortened from 6.5 days to around 2 days, a three‑fold improvement.

Online bug count dropped, quality improved roughly twofold.

Insights and the APD streaming development model

The original weekly iteration could not satisfy the demand for daily releases, so the team adopted the APD streaming development model, which builds on lean‑Kanban principles but adds refined team roles and feedback loops. Scrum‑like roles were introduced to define a minimal set of agile roles.

Team management activities

The team incorporated three core practices: product backlog grooming, daily stand‑up meetings, and retrospective summary meetings. Continuous planning replaces a separate planning meeting, though a dedicated planning session can be introduced if the team’s context requires it.

Tooling

The team used the internally developed Lean Cloud board (see screenshot). Settings were configured to support the streamlined workflow.

Pair programming and code review were practiced during development to ensure code quality.

Process practices

Demand splitting followed the INVEST principle for user stories, keeping work items clear and small. The Lean Cloud board made work transparent; daily stand‑ups, instant planning, and adaptive adjustments kept the flow smooth. Regular summary meetings (technical weekly, project monthly, etc.) enabled multi‑angle retrospectives, fostering continuous learning and improvement.