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)
Artifacts
- 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
Building Agile Teams
- 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
- Operate
Ceremonies / Meetings
- 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.
- Casual way to demo what has been accomplished (holding accountable the team, but celebrating successes)
- 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
- Sprint Planning