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