12 skills.
Use when asked to run an agile chartering session — collaboratively defining a project's vision, objectives, and working agreement with a diverse stakeholder group — as distinct from a formal project charter document (see project-charter), which is written and approved rather than co-created in a session.
Use when asked about the agile coach role — facilitating ceremonies, removing impediments, fostering psychological safety, and evolving from hands-on guidance to strategic coaching as a team matures — as distinct from a Scrum Master's more process-focused role or a traditional project manager (see project-management).
Use when asked to run the delivery track of dual-track agile — building, testing, and shipping validated work via a continuous delivery pipeline — as the track that runs alongside, not after, discovery (see agile-discovery), and grounded in continuous delivery's build/test/deploy/release pipeline.
Use when asked to run the discovery track of dual-track agile — validating what to build before building it, via problem identification, user personas, and prototyping — as the track that runs alongside, not before, delivery (see agile-delivery), and feeds product-management's broader discipline.
Use when asked to run an agile project liftoff — aligning a team on vision, objectives, stakeholders, and initial plan at project start — as distinct from an agile chartering session's working-agreement focus (see agile-charter) or a formal project charter document (see project-charter).
Use when asked what the Agile principles are, to check a team practice or process decision against them, or to explain the reasoning behind agile software delivery (as opposed to a specific framework like Scrum or Kanban, which implement these principles rather than being identical to them).
Use when asked to run a team reflection or retrospective in the spirit of the 12th Agile Manifesto principle — regular, honest process examination followed by actual behavior change — as distinct from a futurespective's forward-looking scenario exploration (see futurespective), which looks ahead rather than back.
Use when asked to run an agile showcase (sprint review) — demonstrating working software to stakeholders on a regular cadence — including whether a team should run one at all, mirroring the same with/without tradeoff agile-standup covers for daily standups.
Use when asked about an agile "stand-down" — an informal end-of-day or end-of-session closing check-in some teams run as the counterpart to a morning standup (see agile-standup). This is a less standardized, less common practice than the standup itself — verify what a specific team actually means by the term before assuming a fixed format.
Use when asked to run a daily standup (daily scrum) — the three-question format, timeboxing, and common failure modes — including whether a team should even run one at all, as distinct from a broader agile-coaching engagement (see agile-coaching) that would help diagnose that question.
Use when asked to set up or run a Kanban board — columns, work-in-progress limits, continuous flow — as an alternative to Scrum's fixed sprints (see scrum), suited to continuous-flow work rather than timeboxed iterations.
Use when asked to set up or run Scrum — roles (Product Owner, Scrum Master, Development Team), artifacts (Product Backlog, Sprint Backlog, Increment), and events (sprint planning, daily scrum, review, retrospective) — as a fixed-sprint alternative to Kanban's continuous flow (see kanban).