agile sdlc

Bhawani Nandan Prasad

Agile Software Development

Life-cycle



Objective

To help you understand the principles of Agile software development and successfully implement the software development life-cycle on your projects

Topics

Agile primer

Why Agile?

Mapping Agile to SDLC activities

Writing good requirements

A typical iteration in Scrum

Software engineering best practices

Wrapping up releases


Why bother about Agile?

Israel Gat: Cutter Consortium:

“Agile can do to software development what internet did to

computing”

“Agile is a train. Either you get on to it or you will be under it”

PMI research: Use of Agile has tripled from December

2008 to May 2011

Gartner: 80% of software development projects would

use Agile by end of 2012

74% of IT professional surveyed had practiced Agile in

some form or other; 55% for 2 years or more

Copyright (c) Sandeep Shouche, CSM, PMP,

PgMP, PMI-ACP 2012


Problems with Software Development

Excessively long “time to market” for products

Customer orientation is lacking

Cost of delivering software is too high Poor productivity of teams

Too much “wasted work” to fix defects and rework designs

Software quality is poor

Ability to responding to change is low

Employee morale is low (and attrition rates are high!)

Project failure rate is too high ~70% or more

Delivered ROI falls short of expectations

Usage of features in a system


Waterfall v/s Agile


Choosing Agile



Choosing Agile

• Are requirements for the finished project complete, clear and

stable?

• Can the effort required to complete the project be easily

predicted?

• Have you successfully completed previous projects similar to

the one you’re about to start?

If you can answer “yes” to these questions, then a plan-driven

process like the waterfall method is likely your best bet. Because

answering “yes” to these questions indicates the project you’re

about to start is predictable to a reasonable degree.

In short, If Project has three factors–urgency, complexity, and

novelty - choose agile


Traditional Software Development

Design

Coding

Testing

DeployAdvantage: Logically sound

Disadvantage: Assumes predictability!

Analysis


Evolution of Agile

Iterative development, done in small incremental

chunks, validating requirements at each step

Agile development evolved in mid-90’s – the

word “Agile” was adopted in 2001

Has significant parallels with “Lean movement”

in the manufacturing world

Is also similar to “spiral models”, except spiral

iterations are longer and rely on “prototypes,

where Agile emphasizes “working software”


Providing early value

Value Realized

Time

Incremental delivery

All-at-once

Delivery


Agile Manifesto – Feb 2001

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 tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items on

the right, we value the items on the left more

Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn,

Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith,

Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C.

Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas

See http://www.agilemanifesto.org

http://www.agilemanifesto.org/


Principles related to SDLC

Principle No.1: Our highest priority is to satisfy

the customer through early and continuous

delivery of valuable software.

Break it up to deliver early and frequently

Principle No.2: Welcome changing

requirements, even late in development. Agile

processes harness change for the customer's

competitive advantage.

Do not be bureaucratic about change management, be

flexible to absorb change


Principles related to SDLC

Principle No.3: Deliver working software frequently,

from a couple of weeks to a couple of months, with a

preference to the shorter timescale.

Typical length of an iteration is 2 weeks to 2 months

Principle No.7: Working software is the primary

measure of progress. The output of each iteration must be “working software”

Principle No.9: Continuous attention to technical

excellence and good design enhances agility.

Design is important, but design is “continuous” – not one time

activity

Agile Unified Process

Four project lifecycle phases

Inception

Elaboration

Construction

Transition

Six engineering disciplines

Business modeling, Requirements, Analysis and Design,

Implementation, Test, Deployment

Three supporting disciplines

Environment, Configuration and Change management, Project

management


Rational Unified Process (Continued)



Scrum Basics

Backlog

Item

Priority

Product

Owner

Inputs from Customers,

Team, Execs, Support,

etc.

Team

Sprint Backlog

Sprint Planning

Meeting

Sprint1-4

weeks

Finished

Deliverables

Sprint

Review

Sprint

Retrospective

Scrum Master

Daily

Standup

Once agreed, Sprint end date &

deliverables do NOT change


Product backlog

List of everything that could ever be of value to the business for the team to produce.

Defined in terms of “epics” and “user stories”

Ranked in order of priority

Priority is a function of business value and risk

Product owner can make any changes they want before start of a Sprint / Sprint Planning meeting

It can be addition of new items, changing or removing or existing items or re-ordering them

Ideally for 2 sprints items should be well defined


Example of Product Backlog

Description Size

Utility to mark all positions to market

at end of trading day 20

Report on outstanding positions for

SEBI filing 10

On-the-fly introduction of securities

into intra-day trading 5

Upgrade server platform to JRE 1.65

Fix intermittent problem with index

window flickering (Defect

No.0002413)

10

Integrate Mark-to-market utility with

trading system (execute every hour) 20

List of requirements in

descending order of

priority

Can be …

Functional or non-

functional

Technical upgrades

Significant bug-fixes


User Stories and Epics

Epic: High-level theme that combines a set of planned features or requirements Examples …Scalability improvements to handle processing rate of

100 transactions per second

Usability improvements

User Story: A short description of a planned feature or requirement. Examples …Modify server code to support multi-threading

Reduce the size of packets sent over

Reduce number of clicks to checkout to 5

Support Section 508 recommendations


Epics and user stories

Can include any or all of the following

New features

Modification or Deletion of existing features

Bug-fixes to existing software

Internal clean-up tasks like code re-factoring,

support for new technologies, etc.

Should all result in “adding value” to the

customer!


User Stories

Should be small

Typically no more than 40 man hours of effort

Should be deliverable as a unit (de-

coupled or loosely coupled)

Should be described in as much detail as

is necessary to “validate successful

completion”

May contain child stories or tasks

Writing good user stories

Example templates

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

E.g. As a account holder, I can check my balances online so that I can

maintain daily balance

Use 3”X5” index cards (ensure that you don’t write too much)

Make it testable by writing acceptance criteria

Given [context] <and/or [some more context]> When [event] Then

[outcome] <and/or [another outcome]

E.g. Given account balance is negative and no direct deposit is scheduled

on the day when the account holder tries to withdraw money then the bank

will deny the request and send the account holder an alert

Connect the dots by thinking of all possible scenarios

More references:

http://www.agilemodeling.com/artifacts/userStory.htm



How to split storiesRef: Bill Wake’s “20 Ways to Split Stories”: http://xp123.com/xplor/xp0512/index.shtml

The Big Picture • Research vs. Action

If a story is too hard, one split is to spend some time researching solutions to it.

• Spike vs. Implementation You can buy learning for the price of a spike (a focused, hands-on experiment on some

aspect of the system).

A spike might last an hour, or a day, rarely longer.

• Main Flow vs. Alternate Flows (Use case terminology.) The main flow - the basic happy path - is usually the one with the

most value.

• Manual vs. Automated If there's a manual process in place, it's easier to just use that for a while before throwing it

away.

• Buy vs. Build Sometimes, what you want already exists, and you can just buy it. For example, you might

find a custom widget that costs a few hundred dollars. It might cost you many times that to develop yourself.

Other times, the "off-the-shelf" solution is a poor match for your reality, and the time you spent customizing it might have been better spent developing your own solution.


How to split stories

User Experience

Batch vs. Online A batch system doesn't have to interact directly with the user.

Single User vs. Multi-User Keep concurrency, access control issues, etc. in abeyance for

some time.

API-only vs. User Interface It's easier to not have a user interface at all. For example, if

you're testing your ability to connect to another system, the first cut might settle for a unit test calling the connection objects.

Generic UI vs. Customer UI At one level, you can use basic widgets before you get fancy

with their styles. To go even further, something like Naked Objects infers a default user interface from a set of objects.

http://www.nakedobjects.org/


20 ways to split stories

“Ilities”

• Static vs. Dynamic It's easier to calculate something once than ensure it has the correct value every time its

antecedents change.

• Ignore errors vs. handle errors While it's less work to ignore errors, that doesn't mean you should swallow exceptions.

Rather, the recovery code can be minimized.

• Transient vs. Persistent Let's you get the objects right without the worries about changing the mapping of persisted

data.

• Low fidelity vs. High fidelity You can break some features down by quality of result. E.g., a digital camera could start as a

1-pixel black-and-white camera, then improve along several axes: 9 pixels, 256 pixels, 10,000 pixels; 3-bit color, 12-bit color, 24-bit color; 75% color accuracy, 90% color accuracy, 95% color accuracy." (William Pietri)

• Small scale vs. large scale "A system that works for a few people for moderate data sets is a given. After that, each step

is a new story. Don't forget the load tests!" (William Pietri)

• Unreliable vs. Reliable "Perfect uptime is very expensive. Approach it incrementally, measuring as you go." (William

Pietri)


Typical life-cycle in a Scrum World

Repeated as long as it

takes to create a

releasable product

High-level Roadmap

For a Release


Release Planning

Aims at coming up with a “long-term roadmap”

What should happen during a release planning? Prepare of a release roadmap with “epics” defined at high level

Estimate of what and how much can be accomplished in a release

Identify and tie up dependencies on external factors or events

Prepare a high-level project plan with milestones

Mode of release planning Usually face-to-face, lasting up to a week

The entire team need not attend– key representatives should

Product Owner and optionally other stakeholders can attend

Advance preparation (understanding epics, priorities, dependencies, etc.) help this go faster


Sprints

Backlog

Item

Priority

Product

Owner



etc.

Team

Sprint Backlog

Sprint Planning

Meeting

Sprint1-4

weeks

Finished

Deliverables

Sprint

Review

Sprint

Retrospective

Scrum Master

Daily

Standup




Sprints!

Refers to an “iteration”

Typically 1-4 weeks long

Produces an enhanced version of the software

All engineering activities (Code, Unit Test, System,

Regression test) must be completed within the Sprint

Should be “near releasable quality”

A “release” or project contains multiple sprints

As many as is necessary to create substantial “value” to

the customer


Sprint at a glance


Sprint Planning Meeting

Backlog

Item

Priority

Product

Owner



etc.

Team

Sprint Backlog

Sprint Planning

Meeting

Sprint1-4

weeks

Finished

Deliverables

Sprint

Review

Sprint

Retrospective

Scrum Master

Daily

Standup




Sprint planning meeting

Goal:

For the team to make good commitment around what it will

deliver by the end of the Sprint

What’s a Good Commitment?

Clearly understood by all

Shared among team

Achievable without sacrificing quality

Achievable without sacrificing “sustainable pace” (heijunka!)

Attended by Team, Product owner, Scrum Master

Usually take 1-2 Hrs for each week of Sprint duration


Sprint Calendar - Example

Mon Tues Wed Thurs Fri

3 4 5 6 7

10Sprint

Planning

11First day of

Sprint

12 13 14

17 18 19 20Last day of

Sprint

21Review &

Retrospective

24 25 26 27 28


How Sprint Planning should work

Clarifying questions about stories asked

Determine how many stories can “fit” into

a Sprint

Stories are broken down to tasks and

assigned to individuals

Estimates may be modified if necessary

Tip: Some pre-preparation (story-

grooming) helps make the meeting short


Sprint backlog (planning template)

Story Task Owner EstimateUtility to mark all positions to

market at end of trading day

Generate and test query to get

open positions

Sanjay 2

Determine formula for M2M

based on regulations

Shreya 4

Call web service to custodial

services for margin calls

Kapil 8

Email notifications to account

owners about margin position

Manish 2

Write and execute unit tests Sanjay 8

Test story end-to-end Murali 16

Upgrade server to JRE 1.6 Changes to the build system

and installer

Larry 8

Try out latest patch of JRE 1.6

to make sure it works

Gaurav 16

Limited regression testing Alex 24


No changes during a sprint!

Once team has committed, no changes can be made to the Sprint deliverables

Details will emerge during Sprint, but no new work or substantially changed work

No Changes to Sprint Duration either

Sprint ends on planned date whether has completed its commitment or not

The Product Owner can …

Change the Product backlog before the next Sprint

Terminate a Sprint (used very rarely)


The team

Backlog

Item

Priority

Product

Owner



etc.

Team

Sprint Backlog

Sprint Planning

Meeting

Sprint1-4

weeks

Finished

Deliverables

Sprint

Review

Sprint

Retrospective

Scrum Master

Daily

Standup



The team!

Usually 7 + or – 2

As low as 3 or as high as 15

Resources can be shared (but ideally should not be)

Can change between Sprints (but ideally shouldn’t)

Can be distributed (but better when co-located)

Is “cross-functional”

Has all the skills necessary to produce another increment of

“potentially shippable” product

Is “self-managing”

Is empowered enough to do whatever it takes to produce the

potentially shippable product, within organizational constraints



Daily Standup Meeting

Backlog

Item

Priority

Product

Owner



etc.

Team

Sprint Backlog

Sprint Planning

Meeting

Sprint1-4

weeks

Finished

Deliverables

Sprint

Review

Sprint

Retrospective

Scrum Master

Daily

Standup




Daily standup meetings

Ground-rules

Every weekday

Whole team attends

Everyone stands

15 minutes or less

Everyone reports three things

What was able to accomplish since last meeting

What will try to accomplish since by next meeting

What is blocking me

No discussion, conversation until end of meeting

Role of testing/QA in Scrum

No separate QA team

Quality is everyone’s responsibility

One team that is responsible for the

product delivery

No more adversarial relationship between Dev

and QA

QA is lot tougher with Agile

Near releasable quality each Sprint is a huge

challengeBhawani Nandan Prasad

Testing best practices

Continuous testing and regression

Automate as much testing as possible

Testers to participate in story elaboration

and estimation

Test early and test often

Close coordination between Developer and

Tester needed

Move towards “test driven development”


Test-Driven Development

Never write a single line of code until there

is a failed automated test

How to do it?

Design: Figure out what you want to do

Test: Write a test to express the design (it

should FAIL)

Implement: Write the code

Test again: Now the test should pass


Test frameworks/tools for TDD

Xunit

Junit (http://junit.org)

cppunit (http://cppunit.sourceforge.net)

Ruby

PHPunit

Jsunit

TAP (Test Anything Protocol)

http://testanything.org

Other test libraries

e.g. http://opensourcetesting.org

Use code coverage tools (e.g. Clover, Emma, Cobertura)


http://testanything.org/

http://opensourcetesting.org/


Orderly closure of Sprints

Backlog

Item

Priority

Product

Owner



etc.

Team

Sprint Backlog

Sprint Planning

Meeting

Sprint1-4

weeks

Finished

Deliverables

Sprint

Review

Sprint

Retrospective

Scrum Master

Daily

Standup




Sprint review

Purpose of Sprint Review

Demo (not just slides) what the team has built

Generate feedback which Product Owner can

incorporate in the product backlog

Decide about “release” of the builds to the

stakeholders (alpha, beta, etc.)

Attended by Product Owner, Managers,

Scrum Master and Team

Usually lasts 2 Hrs

Sprint “done” criteria

Software with all features work as defined by the

user story

All QA testing for completed features is done

with no pending defects

Regression tests pass

All documentation is completed

Planned stories demonstrated to the Product

Owner, Customer and other stakeholders


What happens if Done criteria are not

met?

Incomplete stories move to the backlog

and prioritized again before the next Sprint

Retrospective to determine why the plan

commitment was not met

Under no circumstances can you “extend”

a Sprint!



Sprint retrospective

What it is?

1-2 Hr meeting followed by each Sprint Review/Demo

Attended by Product Owner, Scrum Master, Team

What’s working and what could work better

Why does Retrospective matter

Accelerate visibility

Accelerate actions to improve

It’s a key mechanism of continuous improvements

(Inspect & Adopt)


How to make retrospectives effective

Have fun (e.g. bring in food, recognize star

performers from the previous sprint)

One person facilitates (Scrum Master)

Do not stifle opinion – collect all inputs

Arrive at few (2-3) things to change

Follow up!

Assign specific actions

Token penalty if improvements are repeated!


Engineering best-practices

Continuous integration: “Automated”

nightly builds

Mandatory code reviews (integrated with

code check-ins) and unit tests

Automated testing:

Sanity tests, executed daily

Regression tests, executed per iteration

Test-driven development


Wrapping up the release!

Once the work required for the release is doneFinal readiness checks for a “release”

Can be preceded by one or more “hardening” sprintsNo new features added during hardening

Focus on fixing bugs, packaging, regression testing, performance testing, etc.

Hardening sprints can be split across the release (need not all be at the end)

Resist temptation to bank on hardening sprints to do required bug fixes – it quickly turns into waterfall in disguise

Release “done” criteria

Customer acceptance received

Beta feedback incorporated

Release documentation (e.g. Release Notes, Read me

First, etc.) is completed

Non-functional requirements (e.g. Performance,

Usability, etc.) are tested and validated

Regulatory and compliance requirements are met (e.g.

Section 508, ECCN, License agreements, etc.)

All planned integrations with other products are tested

and working



Release retrospective

What it is?

A retrospective session for an entire release

To draw lessons from the project and use for the future

Bring an orderly closure to the activities of a release

How to make it effective?

Bring in food!

Do some reward and recognition

Preferably bring an external facilitator

Run like a brainstorming session to generate ideas

Use mute mapping to prioritize ideas generated

Summary

Agile teams must master the art of working in

small increments and delivering quickly

Good engineering practices are of paramount

importance

QA must be built into the development process –

automated testing is indispensable

If we are able to delivery early, we create value

faster, and by getting feedback continuously, we

are better able to adapt to the changing

environmentBhawani Nandan Prasad


Thank You

agile sdlc

Technology

bhawani nandan

potentially

product owner

user interface

releasable

sdlc principle

ignore errors

bit color