Reference library
APPENDIX H
Delivery Methodologies, Team Roles, and DevOps Awareness for OFA 1
Adjacent roles and the hats people wear, Waterfall, Agile and hybrid delivery, DevOps awareness, and a Scrum ceremony cheat sheet.
Appendix Overview
A.
Purpose and Scope
- 1.A new OFA quickly discovers that projects are staffed and run in different ways from team to team.
- 2.The same underlying OFA skills - requirements, documentation, testing, communication - get applied differently depending on the delivery methodology and the mix of roles on a given team.
- 3.This appendix gives a foundational OFA enough vocabulary to orient quickly on an unfamiliar project rather than assuming every project works the way the first one did.
Wearing Many Hats: Adjacent and Overlapping Roles
A.
Recognizing Adjacent Roles
- 1.On any given project, an OFA will work alongside, and sometimes temporarily stand in for, several distinct roles.
- 2.In smaller teams it is common for one person to informally wear more than one of these hats at once.
- 3.Recognizing which hat someone is wearing at a given moment matters more than knowing an official org chart.
- 4.For example, a Product Owner making an authoritative prioritization call is a different hat than the same person offering a personal opinion in the hallway.
| Role | What They Primarily Own | How an OFA 1 Typically Interacts With Them |
|---|---|---|
| Product Owner | The prioritized backlog of work and representing stakeholder value for a specific product | Supplies well-documented requirements that the Product Owner can turn into backlog items; does not set priority order themselves |
| Product Manager | Overall product strategy and direction, often across multiple releases or a longer time horizon | Mostly awareness at OFA 1, consistent with the User-Centered Product Vision and Roadmap stewardship area being awareness-only at this level |
| Project Manager | Schedule, budget, and coordination across teams for a defined initiative | Reports status and risks on assigned tasks; escalates schedule-impacting blockers promptly |
| Scrum Master | Facilitating Agile ceremonies and removing impediments for the delivery team | Participates in ceremonies the Scrum Master runs; the OFA's own discovery and communication skills (Module 5) are related but distinct, usually applied to stakeholder conversations rather than internal team ceremonies |
| Business Analyst | The closest external, industry-standard analog to the OFA role itself | Often literally the same work under a different title when working with vendors or partner organizations |
| QA or Test Analyst | Formal test strategy and structured test execution | An OFA 1 supports test execution (Module 7) but does not own overall test strategy design |
Delivery Methodologies: Waterfall, Agile, and Hybrid
A.
Waterfall
Waterfall is a sequential, phase-gated approach.
B.
Waterfall Phase Sequence
- 1.Requirements are fully defined.
- 2.Then design.
- 3.Then build.
- 4.Then test.
- 5.Then deployment.
- 6.Each phase is generally completed before the next begins.
- 7.Its strength is predictability and clear documentation checkpoints.
- 8.Its weakness is that feedback from real users arrives late, after most decisions are already locked in, making it a poor fit for work where requirements are likely to change.
- 9.An OFA still encounters Waterfall-style phases most often in compliance-heavy or infrastructure-heavy initiatives.
C.
Agile
Agile approaches, most commonly Scrum or Kanban, deliver work iteratively and incrementally in short cycles, gathering stakeholder feedback continuously rather than only at the end.
D.
Scrum
- 1.Scrum organizes work into fixed-length sprints with a defined backlog, sprint planning, daily standups, a sprint review, and a retrospective.
- 2.A defined backlog.
- 3.Sprint planning.
- 4.Daily standups.
- 5.A sprint review.
- 6.A retrospective.
E.
Kanban
Kanban instead manages a continuous flow of work with limits on how much can be in progress at once, without fixed sprint lengths.
F.
Expectations for an OFA on an Agile Team
- 1.Contribute to and refine backlog items continuously.
- 2.Participate in relevant ceremonies.
- 3.Keep documentation current in smaller increments rather than producing one large upfront document.
| Dimension | Waterfall | Agile |
|---|---|---|
| Requirements approach | Fully defined upfront before build begins | Defined and refined continuously throughout delivery |
| Feedback timing | Primarily at the end of a phase or the project | Every sprint or delivery cycle |
| Documentation style | Comprehensive, upfront documents | Lightweight, evolving backlog items and living documentation |
| Best suited for | Well-understood, stable requirements, such as regulatory or compliance work | Evolving, feedback-driven work where needs are likely to change |
G.
Blended Approaches
- 1.Most real organizations blend elements of both.
- 2.For example, Agile delivery within a Waterfall-style budgeting or governance process.
- 3.An OFA should expect any real project to only loosely match a textbook description.
- 4.An OFA should ask directly which methodology a new project follows rather than assuming.
DevOps: What It Is and Why an OFA Should Recognize It
A.
What DevOps Is
- 1.DevOps is a cultural and technical practice that combines software development and IT operations to deliver changes more frequently and reliably, built on automation and shared responsibility between the people who build a system and the people who keep it running.
- 2.An OFA does not operate DevOps tooling directly - that belongs to engineering.
- 3.An OFA should recognize a handful of terms that will come up in requirements, testing, and escalation conversations:
| Term | Plain-Language Meaning |
|---|---|
| CI/CD pipeline | An automated process that builds, tests, and deploys code changes, reducing manual steps and manual error |
| Version control (for example, Git) | A system that tracks every change made to code over time and allows changes to be reviewed or reversed |
| Environment (development, staging, production) | A separate copy of a system used at a different stage of readiness; changes normally move through environments in order before reaching real users |
| Deployment | The act of releasing a change into a given environment |
| Rollback | Reversing a deployment because it caused a problem |
| Monitoring or observability | Automated tools that tell a team when something is behaving unexpectedly after a deployment |
- 4.This vocabulary matters most during testing and escalation.
- 5.Knowing to ask "which environment did this happen in" before assuming a defect is affecting real members is exactly the kind of habit that separates a well-scoped escalation from a premature one.
- 6.It connects directly to the real-time-versus-batch-sync tradeoff explored in the Module 10 system integration business case.
Scrum Ceremony Cheat Sheet
A.
Standard Scrum Ceremonies
For an OFA working within a Scrum team for the first time, the following table summarizes the standard ceremonies and what role an OFA typically plays in each.
| Ceremony | Purpose | Typical Duration | OFA's Typical Role |
|---|---|---|---|
| Sprint Planning | Decide what backlog items the team will work on in the upcoming sprint | One to two hours per week of sprint length | Clarifies requirements on backlog items being considered |
| Daily Standup | Quick, daily sync on progress and blockers | 15 minutes | Reports status on assigned items and flags blockers |
| Backlog Refinement | Review and clarify upcoming backlog items before they are planned into a sprint | One hour, roughly weekly | Drafts or refines requirements notes on items being reviewed |
| Sprint Review | Demonstrate completed work to stakeholders and gather feedback | One hour per week of sprint length | Helps confirm whether demonstrated work matches the original requirement |
| Sprint Retrospective | Reflect on how the team worked together and identify improvements | One hour per week of sprint length | Contributes observations, particularly about requirements or documentation gaps encountered |
Practical Guidance for Orienting on a New Project
A.
Orientation Checklist
- 1.Ask directly what delivery methodology a new project follows, rather than assuming it works like the last one.
- 2.Ask who currently holds each adjacent role (Product Owner, Project Manager, Scrum Master, and so on) so questions and escalations reach the right person the first time.
- 3.When one person visibly wears multiple hats, notice which hat they are wearing in a given statement, since an offhand opinion and an authoritative prioritization decision can sound identical but carry very different weight.
- 4.During testing, always confirm which environment an issue occurred in before treating it as affecting real members.