Agile

Notes, thoughts, and ideas on practicing more Agile methodologies in software development, project management and team building

Overarching Thoughts / Concepts

Breaking a large project down into smaller chunks can increase the ability to garner feedback and prepare the product.
- Sometimes this isn’t desired, as we need to sometimes reduce feedback for scope-creep reduction
Product Owners prioritize work, dev teams select work based on capacity (not arbitrary deadlines)

Roadmaps: outlines how a project or solution develops over time.
- Broken down to initiatives with timelines for when those broader features should shoot for release
Requirements: When you break down initiatives, you are left with requirements
Backlog: Sets the priorities for the agile program
Epics or Versions: Basically just the delivery vehicle that wraps up initiatives into deliverables

Agile teams are built upon trust
- Highest performing teams utilize things like code reviews, task branching, CI/CD and regular release cadences in order to build trust in the team.
Remember Tuckman’s 4 stages of team development
- Forming
- Storming
- Norming
- Performing
Agile isn’t just for development teams; think of the entire organization as the product team broken into the three main areas:
- Operate
  - Development
  - Support/Ops
  - Product Management
- Make
  - Development
  - Product Management
  - Design
- Sell
  - Product Management
  - Design
  - Marketing

Important to have these, though just having this sorts of meetings doesn’t mean that you’re Agile; you need to follow the underlying principles, team structures, and development / deployment philosophies
Common Ceremonies include (but are not limited to):
- Sprint Planning
  - Doesn’t necessarily need to be a fast, quick meeting; good rule of thumb is one hour per week included in the iteration (e.g., 2hrs for a 2-week sprint)
  - Take time in here to really think about the stories/bugs that we’re considering, and even draw out subtasks for them in order to really plan well
- Stand-Ups
  - Keep it light, informative, but not overly detailed
  - Answer these questions:
    - What did I work on yesterday?
    - What will I work on today?
    - What am I blocked by?
- Sprint Review
  - Casual way to demo what has been accomplished (holding accountable the team, but celebrating successes)
    - “Demo Fridays”
  - Main purpose is to show working software at the end of the Sprint, holding team accountable for what was committed to at the beginning of the Sprint.
- Sprint Retrospectives
  - Also takes place at the end of the Sprint
  - This meeting is distinctly different than the Review as it’s a time to focus on the continual improvement of the team
    - What worked well -> Let’s keep doing that (reinforcement)
    - What didn’t work well -> Let’s make a plan to avoid it this next sprint