Atlassian Agile Basics

Get Started with Agile

• What’s Agile?
  • Agile project management is an iterative approach to managing software development that focuses on continuous releases and incorporating customer feedback with every iteration
• Waterfall versus Agile
  • Waterfall is a traditional project management style that builds in phases, folding everything into a single, high-risk release
    • Painful to move backwards since teams are always marching forward
    • Creates a critical path, where project can’t move forward until a blocking issue is resolved
    • Customer can’t interact with the product until it’s complete
  • Agile pattern, in contrast, takes an iterative approach to development with regular feedback intervals
    • Iterations enable the team to be diverted to another area of the project while a blocking issue is resolved
    • Gives the team constant opportunities to build, deliver, learn, and adjust
    • Teams are prepared to quickly adapt to new requirements
    • Shared skill sets among the software team adds flexibility to the work in all parts of the code base, so work and time aren’t wasted if project direction changes

• How to Build an Agile Program
  • Transitioning from traditional project management to agile means embracing two important concepts:
    1. Product owners prioritize work, so the development team is doing the highest value work
    2. Development teams select work, pulling the work from the backlog as it can accept new work. The product owner doesn’t commit the team to arbitrary deadlines.
  • Roadmaps outline how a product or solution develops over time
    • Composed of initiatives (large areas of functionality) and include timelines that communicate when a feature is available
    • Should focus on long-term goals
  • Requirements: each initiative in the roadmap breaks down into a set of requirements, which are lightweight descriptions of required functionality. The requirements evolve over time and remain lean while the team develops a shared understanding via conversation/collaboration. Finalized when implementation is about to begin.
  • Backog sets the priorities for the agile program. Consists of all work items: new features, bugs, enhancements, technical/architecture tasks, etc. Product owner prioritizes the work. Prioritized backlog is the single source of truth for the work that needs doing.
  • Agile Delivery Vehicles: various frameworks can be used to deliver software, like Scrum and Kanban
    • Scrum uses sprints
    • Kanban teams work without fixed work intervals
    • Both frameworks use large delivery vehicles like epics and versions to structure development for a synchronized release cadence out into production
      • Difference between epics, stories, versions, sprints outlined here
  • Agile Metrics makes agile teams thrive. Work in Progress (WIP) limits keep the team focused on high priority work. Burndown and control charts help team predict delivery cadence. Continuous flow diagrams identify bottlenecks.
• Agile Runs on Trust
  • Agile programs cannot function without high trust level among team members
  • Difficult, candid conversations need to happen about what’s right for program and product.
  • Conversations should happen at regular intervals, so ideas and concerns are regularly expressed.
    
    
• Main benefit of agile project management is that you can respond quickly to market trends and incorporate customer feedback
• Product owner prioritizes the backlog for the engineering team
• Requirements mechanism is a lightweight description of an individual initiative’s required functionality

Build Agile Teams

• Teamwork
  • Great agile teams embody “we” rather than “I”
• Build Upon a Solid Foundation
  • Agile teams are just like individuals: they take time to grow
  • Agile theorists reference Tuckman’s stages of group development:
    1. Forming: lots of guidance needed from manager, individual roles unclear, process not established
    2. Storming: learning how team decisions are made, purpose more clear but team relationships are not clear
    3. Norming: relationships are understood in the team, commitment to clear goals, beginning to optimize processes
    4. Performing: team is performing well and focused on being strategic, little guidance/oversight required
  • Development becomes awesome once a team reaches performing stage - members trust each other, understand each other’s strengths, and optimize how they build software
    • After a change (new hire, employee departure, etc) the team reverts back to the forming stage as it absorbs the change
  • High-performing agile teams are built on:
    • Trust,
    • Sound engineering practices,
      • Examples: Code reviews, task branching, continuous integration, regular release cadences
    • Continuous mentoring,
    • Shared skill sets,
  • As engineers, it’s important to learn new skills because it makes us more valuable to the organization and better equipped to support each other’s work
• How Agile Teams Collaborate Across Departments
  • Today’s software teams include product managers, designers, marketers, operations, developers, and testers
  • Agile teams should focus around three phases: make, sell, and operate
  • Each phase is supported by three teams (each with five to seven members) that form a triad
    • Each triad is agile in its approach - as the product develops, teams are continuously working on one phase and learning more about the product/market

• High-performing agile teams are built on trust and sound engineering fundamentals

Learn About Agile Ceremonies

• Introduction
  • Meetings (“Ceremonies”) are an important part of agile development
  • Scrum is an iterative, time-boxed approach to agile that uses the term “sprint”
    • Other forms of agile use the more generic term “iteration”
• Sprint Planning (Scrum)
  • At start of sprint, generally an hour per week of iteration (2-week sprint planning meeting takes 2 hours)
  • Attendees: dev team, Scrum master, product owner
  • Product owner brings a prioritized product backlog to the meeting, team estimates the effort involved and forecasts the sprint, the selected work becomes the sprint backlog
  • Use sprint planning meeting to flesh out intimate details of the work
  • Team members can sketch out tasks for all stories, bugs, and tasks that come into the sprint
• Daily Stand-Up (Scrum & Kanban)
  • Once per day in the morning, 15 mins or less
  • Attendees: dev team, Scrum master, product owner, optionally team stake holders
  • Purpose is to quickly keep everyone informed on what’s going on across the team
  • Tone should be light and fun but informative
  • Creates implicit accountability in reporting yesterday’s work in front of the team
  • Each team member should answer:
    • Yesterday’s completed activities
    • Today’s tasks
    • Am I blocked by anything?
  • Some teams use timers or toss a ball to keep everyone paying attention
• Sprint (Iteration) Review (Scrum & Kanban)
  • 30-60 mins, at the end of a sprint/iteration
  • Attendees: dev team, Scrum master, product owner, optionally project stakeholders
  • Purpose is to showcase the work of the team, can be a casual format like “demo Fridays”
  • This is time to celebrate accomplishments and get immediate feedback
  • Work should be fully demonstrable and meet team’s quality bar to be considered complete and ready to showcase
• Retrospective (Scrum & Kanban)
  • 60 mins, at the end of a sprint or milestone
  • Attendees: dev team, Scrum master, product owner
  • Purpose is to get rapid feedback to make product and development culture better
  • Use retrospectives to find out what’s working so the team can keep focused on those areas
  • Even if things are going well, don’t stop having retrospectives
  • Continuous improvement is what sustains and drives development within an agile team