Improving Delivery Efficiency with Suppliers through Agile Principles and Work‑in‑Progress Limits

In most cases, agile transformation occurs more easily in in‑house development; when delivery is mainly performed by third‑party vendors, successful examples are scarce. The author’s recent project relied heavily on a supplier, and agile thinking was not mainstream on the vendor side. As the client, they wanted to improve delivery efficiency for mutual benefit and, after months of practice, devised a new delivery model that implicitly applied agile principles without explicitly mentioning "agile".

Limiting Work‑in‑Progress (WIP) – The team realized that throwing a flood of requirements at the supplier caused constant context switching and loss of focus. By capping the number of concurrent requirements to 15 (covering five subsystems) and enforcing a swap‑in‑swap‑out rule for any additional request, both parties could concentrate on a limited set of high‑priority items, accelerating delivery and ensuring business value maximisation.

Daily Coordination – After weekly delivery planning, the client’s project manager and the supplier’s manager hold daily meetings to review progress and address issues promptly, keeping the work on track.

Requirement Clarification – The article stresses that vague requirements lead to divergent interpretations. It illustrates this with examples (e.g., “fishing gear” could mean a rod, net, or hat) and emphasizes the need to define business value, repeatedly confirm details, and set clear acceptance criteria before development.

Acceptance Criteria and Test‑First Approach – By defining acceptance conditions early, the supplier can embed them into test cases, creating a closed‑loop delivery process. This aligns with the "Begin with the End in Mind" principle and promotes test‑first development.

Continuous Feedback and Improvement – Ongoing sincere communication, regular retrospectives, and systematic issue collection helped both parties refine the process, leading to higher quality and efficiency despite strict security and architectural constraints.

About the Author – The author is an early agile practitioner with experience in extreme programming, Scrum, Kanban, TDD, CI, and BDD, and has authored a book on agile transformation.

Recruitment Notice – The article concludes with a call for DevOps engineers, listing required skills (C#, HTML/CSS, JavaScript, PowerShell, T‑SQL, IDE proficiency, VSTS/TFS, agile certifications) and encouraging interested candidates to contact the DevOps community via the provided QR codes.