MD

Agile Team Organization and Scrum

Agile Team Organisation

Why Agile?

  • Agile is rooted in empirical process control due to the complexity and unpredictability of systems development.
  • Traditional plan-based systems were deemed unsuitable because they assumed an assembly line approach.
  • Empirical process control relies on:
    • Frequent, first-hand inspection
    • Immediate adjustments based on inspection results

Agile Manifesto

  • Values:
    • Individuals and interactions over processes and tools
    • Working software over comprehensive documentation
    • Customer collaboration over contract negotiation
    • Responding to change over following a plan
  • The items on the right are valuable, but the items on the left are more valued.

What Agile Means in Practice

  • Small teams (3-12 software developers)
  • Frequent, short, structured team meetings and informal communication
  • Small deliveries of features for review
  • Customer engagement
  • Maintenance of design and code quality through continual testing, analysis, review, and refactoring
  • Automation wherever possible
  • Frequent review and change of project objectives and priorities
  • Frequent measurement and review of software processes and adjustment to enhance performance

Agile Methods and Practices

  • Various practices associated with agility:
    • Xtreme Programming
    • Scrum
    • Lean
    • Feature Driven Development
    • Crystal Clear
    • Kanban
    • Test driven development
    • Behaviour driven development
    • Planning poker
    • Refactoring
    • Pair programming
    • Retrospectives
    • Continuous integration and deployment

Risks of Agile Development

  • Lack of customer engagement
  • Stakeholder conflict
  • Complex contractual arrangements
  • Loss of organisational memory
  • Poor code quality
  • Poor team coordination or cohesion

What Agile Is Not

  • Doing every single agile practice within a single project regardless of context.
  • Achieving flexibility through uncontrolled change to objectives or process.

Scrum

  • Focuses on the team, project, and process management aspects of software development.
  • Can be used as a wrap around for other agile practices that cover technical concerns.
  • Name is derived from rugby.

Roles (in Scrum and Beyond)

  • Scrum master
  • Product owner
  • Team Manager
  • Quality assurance manager
  • Toolsmith
  • Chief architect
  • UX designer
  • Developer

Managing Work in Scrum

  • Releases are marked by release planning meetings.
  • Some teams begin a first sprint with a project launch meeting.
  • A release comprises one or more sprints.
  • Each sprint lasts (normally) between 1 and 3 weeks.
  • A sprint starts with a planning meeting and ends with a review meeting and retrospective.
  • Stand-ups or scrums take place throughout the sprint

Scrum Workflow

  • Backlog → Sprint Backlog → Incremental Improvement and Delivery → New Deployment → Customer

Project Launch Meeting

  • Determines the major features to be delivered to a customer over a series of sprints.
  • Understand customers long term objectives and identify a minimum viable product.
  • Decide on the goals for within the project course.
  • Develop an initial set of user stories.
  • Refine the user stories into tasks and populate a backlog of issues on GitLab.
  • Triage items in the backlog to establish cost estimates and priorities.

Release Planning Meetings

  • Longer projects will comprise multiple releases, each of several sprints.
  • Identify the high level set of features or improvements to be delivered in a release.
  • Create a roadmap of milestones aligned with your customer priorities and the customer days.
  • Populate the roadmap with key features from the backlog.
  • Assume that these will be changed in the sprint planning meetings.

Sprint Planning Meeting

  • Decide on main goal for the sprint:
    • Major new feature set
    • Performance or other enhancements
    • Bugs to be corrected
    • Code to be improved
  • Select tasks from the backlog on your issue tracker that match the goal.
  • Ensure all selected issues are sufficiently detailed.
  • Cost estimates
  • Priorities
  • Assignees
  • Ensure that task cost estimates are within the project velocity.

Determining Project Velocity - Burn down Charts

  • story points
  • time

Monitoring Progress in Stand-ups

  • Hold a stand-up at least once a week in TP3 during semester 1.
  • Facilitated by the scrum master.
  • Each team member is asked:
    • What did you accomplish last week?
    • What are you working on now?
    • Do you have any blockers?
  • Should not last more than 10 minutes
  • Try documenting the stand up on your wiki to begin with.
  • Experiment with more frequent stand-ups, particularly early on.

Managing Delays - Deadlines or Feature Driven?

  • Adding more resources

Reviewing a Sprint

  • Review the progress on the project in the Sprint Review Meeting
  • Review the software team’s process in the Retrospective Meeting

Sprint Review Meeting

  • Deliver and demonstrate new version of software developed over the course of the sprint.
  • Summarise progress compared with planned work for sprint.
  • Explain reason for deviations from plan.
  • Identify new features to be added to the system.
  • Additional work completed
  • Missed features

Key point

  • Agile methods manage project risk through frequent reviews and small adjustments to project objectives and process.