Agile Is Not a Process — It's a Philosophy

Agile is based on a few core principles from the Agile Manifesto (2001):

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

Most companies practice Scrum, which is a specific Agile framework with defined roles (Product Owner, Scrum Master, Development Team), events (Sprint Planning, Daily Standup, Sprint Review, Sprint Retrospective), and artifacts (Product Backlog, Sprint Backlog, Increment).

Agile exists because software development is inherently uncertain. Waterfall planning fails because requirements change, technology surprises you, and users want different things than you predicted. Agile acknowledges uncertainty and builds in feedback loops.

Your Core Responsibilities in an Agile Team

1. Own the Product Backlog The backlog is the ordered list of everything the team might work on. You're responsible for keeping it current, ensuring every item is clear enough that engineering can estimate it, and ruthlessly pruning items that are no longer relevant.

2. Define the "Why" for Each Sprint Before every Sprint Planning session, know exactly why the team is working on these specific stories this sprint. What's the outcome? What user problem are you moving toward? If you can't articulate this in one sentence, the sprint lacks direction.

3. Be Available During the Sprint Once a sprint starts, your team will have questions, find edge cases, and need decisions quickly. Being unresponsive during a sprint is one of the fastest ways to lose the trust of your engineering team.

4. Accept or Reject Work at Sprint Review Evaluate completed work against acceptance criteria and make a clear call: does this meet the definition of done? Be direct. Vague feedback is worse than no feedback.

The Ceremonies You'll Attend

• Sprint Planning (~2 hours per 2-week sprint) — The team selects backlog items and breaks them into tasks. Your job: make sure stories are clear, answer questions, help the team understand business context.
• Daily Standup (15 minutes) — The team shares blockers. Your job: remove blockers, not run a status meeting.
• Sprint Review / Demo (~1 hour) — The team demos completed work. Your job: accept or reject stories, capture feedback, share direction for upcoming work.
• Sprint Retrospective (~1 hour) — The team reflects on process. Participate honestly and follow through on commitments to improve.

The PM-Engineering Relationship

The single most important relationship you have is with your engineering lead or tech lead. Invest in it early.

• Have a regular 1:1, even if it's just 30 minutes a week.
• Invite engineers into discovery. Let them hear from users directly.
• Be honest about uncertainty. "I don't know yet" is better than a fake answer that changes in two weeks.
• Respect the technical opinion. When an engineer tells you something will take three months, understand the constraints before negotiating.

The best PM-engineering partnerships feel like co-ownership. You're building together, not handing off requirements.

Key Takeaway: In an Agile team, own the backlog, define the "why" behind each sprint, be available and decisive during development, and accept work that meets the bar. The daily standup is the team coordinating, not reporting status to you. Protect that distinction.