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.