# Team Model ### Overview Agile delivery depends on having the right people with the right authority working together at the right time. Teams should be multidisciplinary. A team should not be made only of engineers, only of analysts or only of managers. It should include the skills needed to understand the problem, design the service, build the solution, assure it and operate it. ### Core Roles ### Delivery Lead Owns delivery execution. Responsibilities: * delivery plan * team rhythm * sprint or flow management * RAID management * milestone tracking * reporting * customer governance coordination * blocker escalation * acceptance coordination ### Product Lead Owns product direction and prioritisation. Responsibilities: * product vision * outcomes * backlog priority * roadmap * trade-off decisions * value measurement * stakeholder alignment ### Service Designer Owns end-to-end service understanding. Responsibilities: * user journeys * service blueprints * cross-channel experience * operational handoffs * assisted digital considerations * service pain points ### User Researcher Owns user insight and research quality. Responsibilities: * research planning * recruitment approach * interviews and testing * synthesis * user needs evidence * usability findings * accessibility insight ### Business Analyst Owns structured analysis of business, process, rules and requirements. Responsibilities: * process mapping * requirement clarification * acceptance criteria * dependency analysis * data and rule mapping * operational impacts ### Technical Lead Owns technical direction. Responsibilities: * architecture * engineering standards * technical decisions * integration approach * technical risk * code quality * technical assurance ### Security Lead Owns security and assurance alignment. Responsibilities: * security requirements * data handling * threat modelling * access model * vulnerability management * risk treatment * security evidence ### Engineers Own technical build and implementation. Responsibilities: * code delivery * tests * peer review * deployment scripts * documentation * defect resolution ### Test and Quality Lead Owns test approach and quality evidence. Responsibilities: * test strategy * acceptance testing * regression testing * defect management * evidence capture * quality reporting ### Commercial Lead Owns commercial alignment. Responsibilities: * Statement of Work interpretation * change control * milestone and payment alignment * contract assumptions * IP considerations * supplier commercial alignment ### Supplier Lead Owns supplier coordination where subcontractors are used. Responsibilities: * supplier onboarding * supplier scope clarity * delivery dependencies * supplier reporting * supplier acceptance evidence * flow-down requirements ### Customer Roles Customers should identify: * senior responsible owner * product owner or business owner * operational owner * technical owner * security owner * data owner * subject matter experts * acceptance approver ### Team Size Guidance A good agile team is small enough to communicate quickly and large enough to contain the required skills. Where teams grow, split by product, service area, workstream or capability rather than creating one oversized team. ### Role Clarity Rules * Every backlog item must have an owner. * Every deliverable must have an acceptance owner. * Every risk must have an owner. * Every decision must have a decision-maker. * Every supplier task must have an internal accountable owner. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://framework.aic.io/agile-delivery-playbook/delivery-system/team-model.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.