Designing the Process

A Brief Introduction to Agile Programming

In the beginning, there was the waterfall ...

● AAnalysis, DDesign, IImplementation, TTesting & EEvaluation:– Discrete, linear tasks

– Each step completed before the next step can proceed

Waterfall

● Highly structured● Not very adaptable

Agile: a new paradigm

● Process model that recognizes the significance of change and responsiveness

● Emphasis on adaptability● Same basic “steps” are involved (ADITE), but

throw out linearity and discreteness

Agile view of programming process

● Feedback at each stage– Linkage

– Collaboration

Scrum: Agile for software development

● Scrum is the most prominent example of agile model in the programming world

● Scrum describes both the process and the participants in the process

Scrum as process framework

● Sprint: basic work cycle– 1-4 weeks in duration (assuming 40+ hour weeks)

– Tasks pulled from prioritized list of requirements (top first)

– Working software delivered at end of each sprint

– Fixed duration: end at predefined end date, whether successful or not

Scrum artifacts

● Product backlog– Prioritized list of desired features:

● Customer requirements● Engineering improvements

– Changes frequently● As work gets done● As requirements change● Created & maintained by product owner (more on this

later)

Product backlog: example

Source: onproductmanagement.net

Product backlog: example

Source: http://www.mountaingoatsoftware.com/blog/a-sample-format-for-a-spreadsheet-based-product-backlog

Scrum artifacts

● Sprint backlog (aka release backlog)– Detailed document describing requirements to be

met during current sprint

– Includes time estimates (programmer-hours) for completion of each task

● No more than 16 hours per task● Larger tasks broken down into smaller tasks if estimate

exceeds this limit

Product backlog vs. Sprint Backlog

Source: www.altexsoft.com

Product backlog vs. Sprint backlog

Source: agile.dzone.com

Sprint backlog example

Source: www.mountaingoatsoftware.com/uploads/blog/SprintBacklog.jpg

Scrum artifacts

● User stories (customer requirements)– Used in lieu of conventional (long, detailed)

requirements docs

– Generated by customer (user)● Describe what system needs to do for them● Not limited to UI● Short – 2-3 sentences – non-technical

– Serve purpose similar to use cases● Product owner prioritizes these, may tweak them● Programming team uses these to create time estimates

for sprint

User stories

● Suggested formats:– As a [role], I want [feature] because [reason]

– As a [role], I can [feature]

– As a [role], I can [feature] so that [reason]

● Examples:– As a student, I want to see a list of classes so that I

can register

– As account owner, I can check my balance online

– As a user, I want to search for my customers by their first and last names.

Scrum artifacts

● Burndown chart– Shows ongoing (cumulative) work done &

remaining in sprint

– Updated daily

– Guide for team: on-time delivery of working product

Burndown chart: example

Source: http://upload.wikimedia.org/wikipedia/commons/0/05/SampleBurndownChart.png

Burndown chart: example

Source: http://agilesoftwaredevelopment.com/files/apostimages/Scrum/simple-sprint-backlog.png

Kanban board

● Not really a Scrum artifact (Scrum & Kanban are really two different Agile methodologies) but often associated with Scrum projects

● Visual tool (like burndown chart in that sense) for monitoring project progress

● May be used to visualize sprint backlog

Kanban board examples

Source: http://upload.wikimedia.org/wikipedia/commons/thumb/d/d3/Simple-kanban-board-.jpg/400px-Simple-kanban-board-.jpg

Source: http://www.infoq.com/resource/articles/agile-kanban-boards/en/resources/Fig1_task-board.jpg

Scrum roles

● Product owner: in charge of project backlog; acts as the voice of the customer

● Scrum team: develops the product– Cooperative, self-organizing

– Cross-functionsal

● Scrum master: facilitates meetings, protects & serves the team

The process

● Start with product backlog● Sprint planning meeting

– Product owner & team review high priority items, decide what to implement during this sprint – goal is for team to understand what product owner wants

– Team then focuses on detailed task planning:● Time estimates● Ordering of tasks to maximize both speed & quality of

production

The process

● Daily scrum– Short meeting; team members report

● What they did since last meeting● What they plan to do before next meeting● Any problems getting in the way of progress – scrum

master responsible for helping solve these

The process

● Sprint backlog & burndown chart updated daily● Product owner works with team to “groom”

product backlog on a regular basis:– Refining requirement details

– Splitting large tasks into smaller ones

– Time estimation for new items

– Re-estimation of exising items

The process

● Ending the sprint– Duration is preset – sprint is not extended

– Sprint review: team & product owner inspect & adapt whatever team has produced

– Sprint retrospective: team review of sprint:● What went well● What could be improved● Things to try● Issues to escalate

● Start next sprint cycle

Problems with Scrum

● Mostly, it doesn't work if you don't do it right, e.g.:– Meeting rules not followed

– Goals are unclear

– Key players not available to answer questions

– Product backlog not prioritized well

– Not everyone contributes

Benefits of Scrum

● Puts the “agile” in agile development:– Sensitive to changing requirements

– Doesn't attempt to understand entire project before it's started – emphasizes learning along the way

● Delivers a working product quickly– Customers (via product owner) set priorities

– Products developed according to these priorities