1. Agile Software Development
Bhawani Nandan Prasad

2. Objectives
 Agile Development
Basics
Traditional methods
Iterative development
Benefits of iterative development
Different flavors of Agile
 “Managing” Agile projects
Self-organization and self-management
Tracking Agile projects (without micro-managing)
PMBOK and Agile
 Q&A

3. Problems Companies Face
 Excessively long “time to market” for products
 Customer orientation is lacking
 Over-engineered products (~60% features on a product
are never used!)
 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)
 RoI delivered falls short of expectations

4. Traditional Software Development
Design
Coding
Testing
DeployAdvantage: Logically sound
Disadvantage: Assumes predictability!
Analysis

5. The answer …
 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
 Various flavors of Agile development include …
 Scrum (the most popular)
 Extreme Programming (or XP)
 Crystal Clear
 Adaptive software development
 Feature driven software development
 Dynamic Systems Development Method (DSDM); etc.
 Has significant parallels with “Lean movement” in the
manufacturing world, though they are not necessarily
analogous

6. Providing early value
Value Realized
Time
Incremental delivery
All-at-once
Delivery

7. 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

8. 12 Principles of Agile
1. Our highest priority is to satisfy the customer
through early and continuous delivery of
valuable software.
2. Welcome changing requirements, even late in
development. Agile processes harness change
for the customer's competitive advantage.
3. Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.

9. 12 Principles of Agile (continued)
4. Business people and developers must work
together daily throughout the project.
5. Build projects around motivated individuals.
Give them the environment and support they
need, and trust them to get the job done.
6. The most efficient and effective method of
conveying information to and within a
development team is face-to-face
conversation.

10. 12 Principles of Agile (continued)
7. Working software is the primary measure
of progress.
8. Agile processes promote sustainable
development. The sponsors, developers,
and users should be able to maintain a
constant pace indefinitely.
9. Continuous attention to technical
excellence and good design enhances
agility.

11. 12 Principles of Agile (continued)
10.Simplicity--the art of maximizing the
amount of work not done--is essential.
11.The best architectures, requirements,
and designs emerge from self-organizing
teams.
12.At regular intervals, the team reflects on
how to become more effective, then
tunes and adjusts its behavior
accordingly.

12. Characteristics of Agile Process
1. Modularity
2. Iterative
3. Time-Bound
4. Parsimony - minimal number of activities
necessary to mitigate risks and achieve their goals
5. Adaptive
6. Incremental
7. Convergent - actively attacking all of the risks
8. People-Oriented
9. Collaborative

13. Scrum Basics

14. Product Owner
 Responsible for managing Project RoI and risk
 Responsible for consolidating all inputs into what
the team should produce and turn it into a
prioritized “backlog”
 Participate actively in the sprint planning and
sprint review meetings and is available to the
team throughout the sprint
 Determines release plan and communicates to
everybody

15. The Team

16. The team!
 Ideally 7 people + or – 2
Has worked with as high as 15 and as small as 3
Team can be change between Sprints (better not to)
Can be distributed (better results when co-located)
 Cross-functional
Posses all the skills necessary to produce an increment
of potentially shippable product
 Self Managing
Empowered to do whatever is necessary to produce the
potentially shippable product, within the constraints of
the organization’s standards.

17. Scrum Master!

18. Scrum Master!
 Scrum Master helps the team achieve success
using Scrum by
Serving the team
Facilitate the team’s group interaction to help the team
achieve its full potential
Helps to remove blocks that are surfaced by the team
Protecting the team
Protects team from outside interference or disruption
Supporting the team’s use of Scrum
Organizes and facilitates Scrum related practices
Reminds the team Scrum standards

19. Product backlog

20. Product backlog
 List of everything that could ever be of value to
the business for the team to produce.
 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

21. Example of product backlog

22. Sprint planning meeting

23. 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
 Attended by Team, Product owner, Scrum Master
 Usually take 1-2 Hrs for each week of Sprint duration

24. Sprint calendar – 2 week iterations

25. Sprint backlog

26. No changes during a sprint!
 Once team has committed no changes
 No changes to deliverables
Details will emerge during Sprint, but no new work or
substantially changed work
Product Owner can terminate the Sprint if necessary
 No Changes to Sprint Duration
Sprint ends on planned date whether has completed its
commitment or not
 However Product Owner can make the changes
to the remaining Product backlog before the start
of the next Sprint

27. Daily standup meeting

28. Daily standup meetings
 Every weekday
 Whole team attends (including QA)
 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
 Update of artifacts after standup

29. Closing a sprint

30. Sprint review
Purpose of Sprint Review
Demo (not power point presentation) what the
team has built
Generate feedback which Product Owner can
incorporate in the product backlog
Attended by Product Owner, Managers,
Scrum Master and Team
Usually lasts 2 Hrs
Followed by Sprint Retrospectives

31. 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)

32. Advantages of Agile Development
 Customer is able to see “value” much faster
Near releasable product every 2 weeks!
 Reduces “waste” by continuously validating the
output
 Forces orderly management of changes during
the life-cycle

33. Disadvantages of Agile development
 Scrum doesn’t fix anything, team has to do it
 May feel like things are worse at the beginning due to Scrum
makes all dysfunction visible
 Bad product will be delivered sooner
 Some team or Organization are not ready for it
 Team willingness is important
 Managements active support is important
 Inevitably some people will get fed up and leave
 Partial adoption is worse than none

34. Agile or Waterfall?
If Waterfall is working for you, don’t use
Scrum! – Ken Schwaber
See link: http://leadinganswe rs.typepad.
com/leading_ answers/files/ agile_suitabilit
y_filters. pdf

35. Engineering best-practices
 Teams need to be prepared to work with “minimal”
specifications
 “Test-driven” development
 Continuous integration: “Automated” builds and tests
 Highly functional, motivated teams are needed
 Ability to work in cross-functional teams is critical

36. “Managing” Agile projects
 Note that Scrum does NOT talk about a role for
“Manager” or “Project Manager”.
 So what do Managers do on Scrum projects?
 A project manager or coordinator operating in a “matrix”
environment can be trained to morph into a Scrum Master
 Line managers (who have reporting authority) should …
 Be the “Functional” and/or “Technical” expert
 Help the team understand the larger context of the project
 “Protect” the team during prioritization battles
 Foster the right “culture” in the team
 Act as a mentor or a coach to the team
 Represent the team at external forums
 Be risk managers for the projects

37. Release Planning
 Though Sprint contents can change, there often needs to be a long-
term “roadmap” for software projects – evolved during “release
planning” sessions
 What should happen during a release planning?
 Prepare of a release roadmap with “epics” defined at high level
 High-level guesstimate of what and how much can be accomplished in a
release
 Identify project dependencies on external factors or events
 Prepare and secure approval for 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 be
identified
 Product Owner and optionally other stakeholders can attend

38. Tracking Agile Projects
 Contrary to perception, managers should NOT
micro-manage Scrum teams
 Tracking mechanisms
Daily stand-up meetings
Scrum-of-Scrums (for bringing a number of inter-related
Scrum teams together)
Burn-down chart (automated or manual)
Progress chart
 Common metrics in Agile
Velocity (Stories/Story points delivered/Sprint)
Stories Delivered/Stories Planned
Scrum Maturity Model

39. Burn-down chart

40. Progress chart

41. Agile and Process (Myth V/s Reality)
Myth Reality
Agile means no documentation Agile means “just-enough”
documentation
Agile works on “trust” and is informal,
hence cannot work with CMMi and
other process models
Agile actually enforces discipline and
frequent check points. Many CMMi
Level-5 and ISO certified teams use
Agile
Agile works only with “mature” teams Having a mature team helps, but it is
no different from conventional models
Agile works only when teams are co-
located
Co-location helps communication, but
it is no different from conventional
models
Agile is cowboy programming, does
not allow any time for design
Agile calls for “just-enough” design
effort – nothing stops teams spending
time on design

42. Tools used in Scrum project management
 In principle, Agile likes simple, easy-to-use tools.
Agile projects can very well be managed using
post-its, spreadsheets, etc.
 Some of the other tools in vogue are …
Rally (http://www.rallydev.com/)
Mingle (http://studios.thoughtworks.com/mingle-agile-
project-management)
Scrum Desk (http://www.scrumdesk.com)
VersionOne (http://www.versionone.com/)
X-planner (http://xplanner.org/index.html) (open-source)

43. Agile and PMBOK
 All the Agile practices can be mapped to the
processes in the PMBOK
 Agile is a wonderful framework (mainly) for
executing and monitoring/controling processes
 But 23 processes in the PMBOK have no
matching practice in Agile
 Agile does not obviate the need for conventional
project management methods, but
“supplements” it

44. Agile and Program Management
Programs may contain components
(projects) executed in the Agile model
The challenge is to make sure that
dependencies are identified out and
honored
Projects to compromise flexibility for
getting more predictability in programs

45. Iteration Wise Features & Dependencies
Product = <name> IC #1 IC #2 IC #3 IC #4 IC #5 IC#6 IC >6
Key Features/
Themes in IC
1. Asset &
Network
Discovery
(without
Topology)
1. Agent
detection
2. Normalization/
reconciliation
of Windows
data with CD
1. Normalizatio
n of
Windows
and Unix # 1
2. Agent
detection –
queries and
GUI
configuration
• Normalized
Unix and
Windows
asset
discovery # 2
• GUI-based
Domain
import
• New database
support
(Oracle 10g,
SQL Server
2005)
• GUI wizard
optimization
(grouping
methods)
1. Model
convergence to
CDM (Classes
and atributes)
2. Unix &
Windows
normalization
3. Map sharing,
4. export (filtering
per instance via
GUI)
5. Wizard
parameters
ordering
1. GUI features and
model change
finalization
2. Other discoveries
and asset data
normalization
(tokenid generation
and export to CDM)
3. Domain hostname
management (allow
hostname entry)
4. Wizard paramenters
ordering
1. Bug-fixes
2. Integration with any revised
drops
3. Documentation
Delivered On:
Best Case Date =
Most Likely Date =
Worst Case Date =
12/20/2006
12/16/2005
12/23/2005
1/17/2006
01/13/2006
01/17/2006
01/21/2006
1/31/2006
01/27/2006
01/31/2006
02/06/2006
02/16/2006
02/10/2006
02/14/2006
02/21/2006
02/21/2006
02/24/2006
02/28/2006
3/1/2006
3/6/2006
3/8/2006
Product dependencies (need) IC #1 IC #2 IC #3 IC #4 IC #5 IC #6
<Project>
(by worst case date)
ABC 2.0
locked
down
12/9/2005
Unit tested
drop of
XYZ 5.3
1. ABC 2.1
early
access
drop
1. ABC 2.1 early
access drop
1. XYZ 5.3
release
candidate
drop
XYZ 5.3 release
candidate
drop)
XYZ 5.3 release candidate
drop
<Project>
(by worst case date)
<Project>
(by worst case date)
<Project>
(by worst case date)

46. Integrations and Dependencies
 NOT on Track  Concern  On Track
Product using this
product
Suppor
ted
Revisio
ns
Stat
us Comments, Issues, notes
ITSM 7.0 
SIM (via CMDB) 7.0 
Product dependency
(used by this product)
Suppor
ted
Revisio
ns
Stat
us Comments, Issues, notes
CMDB 2.0 
Mostly on track. Only issue is that TD
needs “early access” drops of CMDB
before the drop dates to ensure that
nothing blocks the inter-op cycle
Marimba CD 7.0 
Need to discover Marimba agent and
reconcile output with CD

47. Important links
Scrum Alliance
www.scrumalliance.org
Wikipedia on Scrum
http://en.wikipedia.org/wiki/Scrum_(developmen
t)

48. Thank You