In short
This track is for you if you have a roadmap. Now you must manage the work. You may be a developer or a founder. You will choose a rhythm on purpose: Scrum, Kanban or a mix. You will keep an ordered backlog and write stories that an agent can build. You will plan a cycle and write a definition of done. You will hold a review and a retrospective that lead to decisions.
Agents build fast, so review time becomes the limit. Protect it. You keep a list of changes that your reviews caused. On the agent ladder, your definition of done is the first written policy.
Key words
- Agile: A way of building a product in small steps. You release a little, learn from real use, then change the plan. See Choose your rhythm.
- Scrum: An agile framework with fixed-length sprints, set roles and set meetings. The team builds the product in small steps. See Choose your rhythm.
- Backlog: An ordered list of work waiting to be done: wanted features and fixes. The top items come next. See The backlog.
- Definition of done: A written list of checks that work must pass before it counts as done.
- Acceptance criteria: Checks that prove an issue or epic is done. A person must be able to test each one.
Agile delivery is how a plan becomes working software without the plan going stale. You have a roadmap. Now you need a rhythm that turns one milestone into something a person can use, week after week, and tells you early when you are off course.
This track is short on theory and long on practice. It uses the free guidance from Atlassian, the Scrum Guide and the UK government’s service manual, and it keeps one question in front of you: what does the manager decide, and what does the manager check?
Who this track is for
You have a roadmap, or you are writing one, and you need to run the work. You may be a developer who has lived inside someone else’s sprints and now has to design them. You may be a founder who has never run a delivery cycle. If you have not yet cut an epic into milestones, do the roadmapping and epics track first, because agile delivery starts from a milestone with acceptance checks.
What agile is, and what it is not
Agile is a way of working in short cycles, learning from real use and changing course. It is not a set of meetings, a tool, or a licence to skip planning. Teams that hold every ceremony and still ship late are doing agile theatre. Teams that ship a small, checked slice every week and change the plan from what they learn are doing agile.
Two families of method are common. Scrum works in fixed-length cycles called sprints, with set events and roles. Kanban works as a continuous flow with limits on work in progress. Many teams mix them. The first lesson helps you choose on purpose.
What changes when agents do the building
Agents change the speed of building, not the need for rhythm. They make three things harder to ignore:
- Estimates stop meaning what they meant. Points that measured human effort say little about agent work. You will think in terms of the size of the slice and the cost of checking it.
- Review becomes the bottleneck. An agent can produce a merge request in minutes. A person must still judge it. Your cycle has to protect review time.
- Ready and done matter more. An agent cannot ask a colleague in the corridor what you meant. A story that is not ready produces a guess, and a definition of done that is not written produces a different standard each time.
How the four lessons build
- Choose your rhythm. Agile, Scrum and Kanban in plain words, and how to pick.
- Backlog and stories. An ordered backlog, refinement, stories, acceptance checks and a definition of ready.
- Plan the cycle and define done. Sprint planning, estimation, and a written definition of done.
- Review, retrospect and improve. Demos, retrospectives, stand-ups and metrics, with agents in the loop.
Each lesson has the same shape as the rest of the Dojo’s tracks: why it matters, key ideas, steps, a worked example with the fictional product TrailMug, working with AI agents, common mistakes, a practice exercise that ends in a file in your repo, a checklist and links to free outside learning.
The 2030 Product Development Manager at work
The manager decides the rhythm, the order of the backlog, what counts as done and what the team will not do this cycle. The manager delegates the drafting of stories, the building and the first checks to agents, with a written brief, and verifies by running the acceptance checks on the real product. Several disciplines are involved in every cycle. Engineering judges feasibility and review. Design judges what the person sees. Operations judges whether it can run. Finance asks what the cycle costs, including agent usage. Support and sales need to know what is changing.
Each lesson also places its work on the agent ladder: use one agent, delegate whole tasks with a brief, orchestrate several sessions, and govern them with written policy, hooks and gates. The agent orchestration track covers the upper rungs. In agile delivery, the definition of done, the limits in a brief and the review step are the first policy and gate.
How it maps to the Dojo
- Developer, week 4: Defend the roadmap. Lessons 1 and 2 support the weekly rhythm and the backlog behind it.
- Developer, weeks 5 and 6. Lessons 3 and 4 give you the cycle that produces the brand work, the catalogue, the demo and the package.
- Master Developer. Your definition of done, your decision log and your retrospectives are strong evidence of delivery you can explain without notes.
Time needed
Plan about three hours per lesson, plus a real cycle between lessons 3 and 4. Lesson 4 is only useful after you have run a cycle, even a one-week one.
What you will keep
A written rhythm, an ordered backlog in git, stories with acceptance checks, a definition of ready and a definition of done, notes from a real review and a real retrospective, and a short list of changes you made because of them.
