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

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
Sprint
1-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.6
5
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.

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
Sprint
1-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
Sprint
1-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
10
Sprint
Planning
11
First day of
Sprint
12 13 14
17 18 19 20
Last day of
Sprint
21
Review &
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 Estimate
Utility 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
Sprint
1-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
Sprint
1-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
challenge

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)

Orderly closure of Sprints
Backlog
Item
Priority
Product
Owner
etc.
Team
Sprint Backlog
Sprint Planning
Meeting
Sprint
1-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 done
Final readiness checks for a “release”
 Can be preceded by one or more “hardening”
sprints
No 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
environment

Thank You

Agile sdlc

More Related Content

What's hot

Viewers also liked

Similar to Agile sdlc

More from Bhawani N Prasad

Recently uploaded

In this document

Agile sdlc