From Wikipedia:

Its a group of software development methods based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams........

Manifesto for Agile Software Development

`We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions - over processes and toolsWorking software - over comprehensive documentation

Customer collaboration - over contract negotiationResponding to change - over following a plan

That is, while there is value in the items onthe right, we value the items on the left more.

Traditional “Waterfall” Approach

DetailedDesign

DetailedDesign

Concept Concept

Build Build

Agile Process

Concept

DetailedDesign

DetailedDesign

Build Build

DetailedDesign

DetailedDesign

Build Build

SprintReview

SprintReview

SprintReview

SprintReview

Agile processes are based on a contionous process of Design it, Build it, Test it, Ship it.

Being Agile – What's involved ?

Goal

Deliver high value, high quality working s/w quickly & frequently

Ceremonies

Training

Release Planning

Iteration Planning

Daily Stan-up

Review / demo

Retrospective

Techniques

Iterations

User stories

Co-location

Task board

Burn chart

Planning Poker

Done-done-done

Pairing

Unit Test

Continous integration

Participate

Fundamentals

Short feedback

loops

Inspect & adapt

Collaboration & teamwork

Agile Myths

- No documentation

- No scope management

- No design

- 100% automation

- Only iterative development

- No architecture

- No strick deadline (I can change my mind whenever I want to)

Scrum&

Extreme Programming

Scrum Principles✔ Time-boxes

✔ Cross-functional teams

✔ Open communications

– Within team– With stakeholders

✔ Priorities set by Product Owner

✔ Demonstrable results

✔ Responsive to change

ScrumRoles

- Scrum Master- Scrum Team- Product Owner- Stakeholders

Sprint

Artifacts- Product Backlog- Sprint Backlog- Burn down / up charts

Meetings- Sprint Planning- Daily Stand-up- Sprint Review- Sprint Retrospective

Roles* Scrum Master

Not “command & control” project managerProcess coach and team facilitatorRemover of roadblocks

* Scrum TeamIndividuals responsible for the Sprint resultsMix of skills representing multiple disciplinesUsually 6-8 individuals

* Product OwnerIndividual responsible for productResponsible for product profitability (ROI)Adjusts feature list and priorities for each SprintAccepts or rejects work results

* Users & StakeholdersInterested in results but not responsible for deliverables

The Sprint

* Time boxed effortUsually 2 weeks to 1 monthCan be longer or shorter

* Defined workloadNo changes once Sprint is begun

* Begins with Planning Meeting

* Ends with demonstrable Release

Product Backlog

Product Backlog

* All features and functions for final product

* May be subdivided into releases

* Prioritized by Product Owner

* Initial backlog is established and releases are defined prior to start of Sprints

* Product backlog is reviewed and updated throughout the project

* Time must be allotted during Sprints to allow for this activity

Sprint Backlog

* Features and functions targeted for a single Sprint- Frequently broken down into User Stories; Especially if function is complex

* May include technical requirements or objectives- e.g.; database design, UI standards, architecture documentation

Burnup Charts

Sprint Planning

* Product Owner and Team

* Review of Product Backlog

* Product Owner provides definition and details of features and functions

* Negotiation of what will be in Sprint

* May identify new Product Backlog needs

* Results in Sprint Goals

Daily Stand-up

Daily Stand-up

* Standup 15 minute meeting

* Each team member answers 3 questions:- What have you done since the last meeting?- What will you do before the next meeting?- What is preventing you from accomplishing your tasks?

* For benefit of other team members

* Not a “status report” to the ScrumMaster

Sprint Review

* Results of Sprint are demonstrated to Product Owner

* Owner accepts or rejects results

* Results are input to:- Next Sprint Planning meeting- Sprint Retrospective

Sprint Retrospective

* Meeting with Sprint Team- May include Product Owner

* Process review and modification

* Lessons learned applied in following Sprints

* Techniques– Mute Mapping– Brainstorming

Mute – Mapping Technique

INDEX CARD 4”X6”

Three Parts (3 Cs)

Card

Conversation

Confirmation

User Story

I N V E S T

The acronym INVEST stands for,

I – Independent, N – Negotiable, V – Valuable, E – Estimable, S – Small, T - Testable

User Story

Provides a simple medium for

– Gathering basic information about stories,

– Recording high-level requirements,

– Developing work estimates, and

– Defining acceptance tests

Acts as agreements between customers and team members to discuss detail requirements during an iteration

Example : User Story Card (Formal)

As a <role>,

I want <goal/desire>

so that <benefit>

As a

Who wants this piece of functionality

I want

What the user wants

So that

Why the user wants it

As an employee, I want to purchase a parking pass so that I can park my car safely in the basement and save money.

Priority : 8

Estimate : 4

Theme and Epic

Theme is a set of related user stories that may be combined together and treated as a single entity for either estimating or release planning

Epics are large user stories with

lower priority. They are too big to implement in a single iteration and therefore they need to be disaggregated into smaller user stories at some point

Velocity

* Velocity is a measure of a team’s rate of progress per iteration.

* It is calculated by summing the number of story points assigned to each user story that the team completed during the iteration

Question :

The project team completes four stories in one iteration,

Story A – 5, Story B – 3, Story C – 7, Story D – 5. Calculate the Velocity?

Answer :

Summing up the story points assigned to each user story gives the velocity.

Hence velocity = 5+3+7+5 = 20

Prioritizing Requirements - MoSCoW

Agile Estimation

Agile Estimation

Estimating Size with Story Points

Story Points are the unit of measurement for expressing the overall size of a user story, feature, or other piece of work.

Story Points

The “bigness” of a task is influenced by,• How hard it is (complexity)• How much of it there is (effort involved)• How risky it is

Relative values are what is important:• A login screen is a 2, A search feature is an 8.

Estimate using the relative values• Select the smallest story and estimate as 1 story point• Select a medium-sized story and estimate it as 5 story points

Planning Poker

An iterative approach to estimating Steps

- Each estimator is given a deck of cards, each card has a valid

estimate written on it - Customer/product owner reads

a story and it’s discussed briefly - Each estimator selects a card

that’s his or her estimate - Cards are turned over so all can

see them - Discuss differences (especially

outliers)- Re-estimate until estimates

converge

Extreme programming

Extreme programming has been described as following practices

Fine scale feedback - Pair programming - Test-driven development

Continuous process - Continuous integration - Refactoring or design improvement - Small releases

Shared understanding - Coding standards - Collective code ownership - Simple design

Testing - All code must have Unit tests - All code must pass all Unit tests before it can be released. - When a Bug is found tests are created before the bug is addressed

XP

Pair Programming

* Better Code* Collective Code Ownership* Mentoring* Increased discipline* Improved morale* Team cohesion

Unit Testing

* Unit Testing reduces the level of bugs in production code.* Unit Testing saves you development time.* Automated tests can be run as frequently as required.* Unit Testing makes it easier to change and refactor code.* Unit Testing can improve the design of code especially with

TDD.* Unit Tests are a form of documentation.* Unit Testing inspires confidence!* Unit Tests are a measure of completion.* Unit Testing is FUN!

Coding Standards

• Code Integration

• Team Member Integration

• Maintenance

• Uniform Problem Solving

• Minimizes Communication

• Minimizes Performance Pitfalls

• Saves Money Due to Less Man Hours

CI * Say goodbye to long and tense integrations

* Increase visibility which enables greater communication

* Catch issues fast and nip them in the bud

* Spend less time debugging and more time adding features

* Proceed in the confidence you’re building on a solid foundation

* Stop waiting to find out if your code’s going to work

* Reduce integration problems allowing you to deliver software more rapidly

CI – Reminder / Rules

* Check in frequently* Don’t check in broken code* Don’t check in untested code* Don’t check in when the build is broken* Don’t go home after checking in until the system builds-----* Maintain a Single Source Repository* Make Your Build Self-Testable* Every Commit Should Build the Mainline on an Integration Machine* Keep the Build Fast* Everyone can see what's happening* Automate Deployment-----* Detect integration errors as quickly as possible * Assumes a high degree of tests * Always have a deployable build* Generate metrics to guide project management* Continuous Integration is Vital for Agile Development

Q & A