Chapter 3 - Agile Software Development

CS 3354

Plan-driven Development

An approach to SWE that’s based around separate development stages.

Outputs are to be produced at each of these stages that are planned in advance.

Not necessarily Waterfall Model (plan driven, so incremental development is possible)

Iteration occurs within activities

Agile Development

Emerged in the late 1990s with an aim to radically reduce delivery time for working software systems

Program specification, design, and implementation are interleaved

System is developed as a series of versions/increments with stakeholders involved in version specification and evaluation

Frequent delivery of new versions for evaluation

Extensive tool support is used to support development

Minimal documentation (focused more on working code)

When to use Agile instead of Plan Driven Methods?

When its realistic to have an incremental delivery strategy, where you deliver the software to customers and get rapid feedback

When the system can be developed with a small co-located team who can communicate informally (smaller systems with smaller teams)

When to use Plan Driven instead of Agile Methods?

When it’s important to have a very detailed specification and design before moving to implementation

When creating large systems that require larger development teams

Agile Methods

Focused on code rather than design

Based on iterative approach to software development

Intended to deliver working software quickly and evolve this quickly to meet changing requirements

Aim is to reduce overheads in the software process by limiting documentation and being able to evolve quickly to new requirements without much rework

Principles of Agile Methods

Customer involvement, incremental delivery, “people not process”, embrace change, maintain simplicity

Agile Manifesto

Values individuals and interactions over processes and tools

Values working software over comprehensive documentation

Values customer collaboration over contract negotiation

Values responding to change over following a plan

Issues Addressed by Agile

High requirements volatility

Bureaucratic, heavyweight processes and methodologies

Communication with the customer and other stakeholders

Communication with the team

Poor estimating and planning (ie a shift to adaptive lifecycle)

Agile Methods/Techniques

Extreme Programming (XP)

Adaptive Software Development (ASD)

Dynamic Systems Development Method (DSDM)

Crystal

Lean Software Development (LSD)

Agile Modeling (AM) (includes Scrum, Feature Drive Development (FDD) and Kanban)

Agile Unified Process (AUP)

Extreme Programming (XP) Technique

An Agile technique that takes an “extreme” approach to iterative development

New versions must be built several times per day and increments are delivered to customers every 2 weeks. All tests must be run for every build and builds are only accepted if tests run successfully.

CRC: class-responsibility-collaborator

Agile Project Management

Responsibility of software project managers is to manage the project so that software is delivered on time and within the planned budget

Standard approach is plan-driven, where managers draw up a plan for the project’s deliverables (what they are, when to deliver, and who works on it)

HOWEVER, in Agile Project Management, this is adapted to incremental development and the practices used in Agile Methods.

Scrum Agile Technique

An agile method/technique that focuses on managing iterative development rather than specific agile practice, helping to generate value through adaptive solutions for complex problems.

3 Phases of Scrum

1) Outline planning where you establish general objectives and design architecture

2) Series of sprint cycles where you incrementally develop the system

3) Project closure phase that wraps up the project and completes required documentation (system help frames, user manuals) and assesses lessons learned

6 Characteristics of Scrum

Dedicated developers

Must have experienced developers

Small co-located team (less than 10)

Tools to support testing and configuration

Easy access to users (answers questions)

Short increments and frequent delivery to real users

Scrum Development Team

Self-organizing/managing group of software developers (<= 7 people, or 7+-2 members) responsible for developing the software or other essential project documents

Cross-functional (includes testers and non-developers too)

Negotiates commitments with Product Owner, one sprint at a time

Has autonomy regarding how to reach commitments

Intensely collaborative

Most successful when located in 1 team room (especially for first few sprints) and with long term, full-time membership (moves work to flexible team instead of moving/splitting people to work)

Has a leadership role

Potentially shippable product increment

A software increment that is delivered from a sprint; idea is for the increment to be “potentially shippable” (ie in a finished state with no further work).

Not always achievable.

Product Backlog

Master list of all “to-do” items desired in the product that the Scrum team must tackle (software and/or documentation).

Developers who will be doing the work are responsible for the sizing of smaller more precise items during Refinement, but Product Owner may influence them by helping them understand and select trade-offs.

Each item in it has:

• a description

• a priority (ordering)

• an estimation of the effort needed to complete it

Items usually are captured in the form of “user stories”

Item = Feature = Requirement = User Story

Priority = Ordering = Importance

Product Owner

An individual or small group whose job is to identify product features/requirements, prioritize these for development, and continuously review product backlog and expectations as final arbiter to ensure project continues to meet critical business needs.

Can be a customer, product manager, or other stakeholder representative.

Has a leadership role and is accountable for maximizing value of product or ROI resulting from work of Scrum Team

Responsible for accepting/rejecting each product increment, deciding on when to ship and when to continue development, and for considering stakeholder interests

Still contributes as a team member

Scrum

A daily meeting of the Scrum team that reviews progress and prioritizes work to be done that day

Ideally short and face-to-face that includes the whole team

Scrum Master

Facilitates the Scrum process by arranging daily meetings, tracking backlog of work to be done, recoding decisions, measuring progress against the backlog, and communicating with customers and management outside the team.

Responsible for interfacing with the rest of the company and for ensuring that Scrum team is not diverted by outside interference

Has leadership role and creates an environment conductive to team self-organization

Captures empirical data to adjust forecasts and enforces timeboxes

Keeps Scrum artifacts visible and promotes improved engineering practices

Has NO management authority over the team (anyone with authority over the team is not its Scrum Master). Scrum developers are adamant that Scrum Masters should not be thought of as a project manager (though its not easy to see the difference to others)

Sprint

A development iteration of fixed length events, usually 2-4 weeks long

During the sprint:

• no changes are made that would endanger Sprint Goal

• quality doesn’t decrease

• Product Backlog refined as needed

• Scope clarified and renegotiated if needed with the Product owner as more is learned

Sprint could be cancelled if Sprint Goal becomes obsolete (can only be done by Product Owner)

Velocity

Estimate of how much product backlog effort that a team can cover in a single sprint, rather than duration, in terms of story points per iteration.

Understanding team’s velocity helps estimate what can be covered in a sprint and provides a basis for measuring improving performance

Scrum Guide

Requires Scrum Master to foster an environment in which:

1) Product Owner orders work for complex problem into a Product Backlog

2) Scrum Team turns a selection of the work into an Increment of value during a Sprint

3) Scrum Team and stakeholders inspect results and adjust for next Sprint

4) Repeat

Scrum Process Flow

Scrum Team

Development team consists of 1 Scrum Master, 1 Product Owner, and developers

No sub-teams or hierarchies

Cross-functional (members have all skills necessary to create value in each Sprint)

Self-managing

Small (<=10 people)

Large projects may have multiple, cohesive Scrum Teams (Scrum of Scrums, Team of Teams) with the same product goal, product backlog, and product owner

Team Building

Strategies for allocating people into teams:
1) let a designated person do the allocation
2) let the teams do it themselves

Combination of both works best as:
1) Cross-component teams rather than component-specialized
2) Having part-time team members is NOT GOOD IDEA
3) Designated fire-fighting team was basically an attempt to solve a Scrum bootstrapping problem

Scrum Events

A sprint is a container for all other events, such as:

1) Sprint Planning

2) Daily Scrum

3) Sprint Review

4) Sprint Retrospective

Sprint Planning

Why?: Sprint goal communicates why sprint is valuable to stakeholders

What?: Through chats with Product Owner, developers select items from Product Backlog to include in current sprint, which the Scrum Team may refine during this process

How?: Work is often done by decomposing Product Backlog times into smaller work items of 1 day or less

Sprint Backlog = Why + What + How

Usually timeboxed into a max of 8 hours for a 1-month sprint.

Negotiating the Sprint Plan

Developers decide how many stores to include in the Sprint based on gut feel and velocity calculations

To fit a story in, Product Owner could reprioritize, change scope of different story, or split another story

This face-to-face negotiation occurs during Sprint Planning Meeting (ie the What? of Spirit Planning)

Sprint Backlog

The Sprint Goal, the Product Backlog items selected for the Sprint,
plus the plan for delivering them are together

Scrum Sprint Cycle

Starting Point: Product backlog

Selection Phase: involves all the project team who works with customer to select features and functionality from backlog to be developed during the sprint

Once these are agreed, team organizes themselves to develop the software. During this, team is isolated from customer and organization, with all communication channeled through the Scrum Master.

At the end of the sprint, work done is reviewed and presented to stakeholders. The next sprint cycle then begins.

Sprint Rules

Use small interdisciplinary teams

Build clean interface software

Intelligent management required

Solid systems architecture and framework upfront

Prototype all new tools and technology

Develop infrastructure first

Each Sprint results in an executable

Develop, document, and test in parallel

Daily Scrum

Short daily meetings (usually 15 min) where all team members share info, describe progress since last meeting, problems that have arisen, and what is planned for the following day (can use this to replan short term work)

Purpose: inspects progress towards Sprint Goal and adapt Sprint Backlog as necessary to adjust upcoming planned work

Three Questions:

• What did you do since last Scrum?

• What got in your way?

• What are you going to do before next Scrum?

All pigs (committed) must respond

All chickens (involved) can attend, but must be silent

No new backlog can be introduced externally, backlog can only be added internally

Sprint Review

Purpose is to inspect outcome of Sprint and determine future adaptions, usually timeboxed into a max of 4 hours for a 1-month sprint

Focused outward on product (work completed, feedback from stakeholders, adjusting product backlog)

Sprint Retrospective

Purpose is to plan ways to increase quality and effectiveness, usually timeboxed into max of 3 hours for a 1-month sprint

Focused inward on process (reflect on how the team worked together and improve, goal is to increase team efficiency for future sprints)

Scrum Team inspects how last Sprint went with regards to individuals, interactions, processes, tools, and their Definition of Done

Scrum Team discusses what went well, what problems were encountered, and how those problems were (or weren’t) solved

Scrum Artifacts

Product Backlog, Sprint Backlog, Increment

Each artifact contains a commitment:

• Product Backlog → Product Goal

• Sprint Backlog → Sprint Goal

• Increment → Definition of Done

User Story

Describes functionality that will be valuable to either a user or purchaser of a system; a “promise” to have a discussion, not every detail needs to be included.

Parts of User Story:

• Card: written description of story used for planning and as reminder

• Conversation: about the story to flesh out details

• Confirmation: details used to determine when story is complete

Template Format:
“As a <type of user [role]>, I want <capability [feature]> so that <business value [benefit]>.”

Factors in Prioritizing User Stories

Financial Value

Cost of developing

Learning and new knowledge (both product and project knowledge)

Risk

Business value + high risk + architecture spanning

INVEST Properties

A guide to write effective user stories, includes:

• Independent

• Negotiable

• Valuable to users or customers

• Estimable

• Small (can be completed in single sprint w/ <=25% of the team)

• Testable

Tech Stories

Focus:
Technical improvements

Value:
Indirect benefit to user

Priority:
Essential for long-term health but often lower priority

Example:
Upgrade database to newer version, install new security patch, optimize app performance

Support Stories

Focus:
Maintenance and bug fixes

Value:
Directly benefit user by preventing issues

Priority:
High priority if it impacts user experience or system stability

Example:
Fix critical bug, code refactoring, update documentation

Agile Estimation Concepts

Story Size, Story Points, Velocity

Story Size

Normally strive for stories weighted around 2-8 days

Around 10 stores per sprint, usually someone between 5-15 though.

Stories vs. Tasks

Time estimates are easier to do and more accurate if story is broken down into tasks.

Stories = deliverable stuff that Product Owner cares about

Tasks = non-deliverable stuff, or stuff Product Owner doesn’t care about (no need to involve them)

Scrum Board

Division of Concerns (Kniberg)

Setting relative importance of requirements and the estimates for doing the work are divided.

Product Owner: sets scope and importance of requirements

Development Team: sets estimates for doing the work

Definition of Done (DoD)

Set of criteria that must be met for a product increment to be considered complete and ready for release (Ken Schwaber)

If Product Backlog item doesn’t meet DoD, it cannot be released or presented at Sprint Review

Does Agile Fit Your Needs? (Boehm)

Based on Personnel, Criticality, Dynamism, Size, and Culture

Barriers to Success of Agile

Customer who insists on big specification

Culture that requires long hours to prove commitment

Environment with a long time to gain feedback or realistically test software

Why Scrum is Powerful

Focus and autonomy

Transparency

Adaptation

Breaks down complexity

Delivers value incrementally

Trust

Positive culture