2. Essence of Agile
Overview of Agile Methods (XP, Scrum)
Agile and Traditional Development Methodology
APM (Agile Project Management Framework)
Myths about Agile
Agile Planning
User Stories
Agile Estimation
Timeboxing
Burn Down / Burn up Charts
Kanban Board
2
3. In the struggle for survival, the fittest win out at the expense of
their rivals because they succeed in adapting themselves best
to their environment.
—Charles Darwin
www.izenbridge.com 3
4. The United States Department of Defense (DoD) and NASA
have used iterative and incremental development (IID)
since the 1950s
In the 1960s, Evolutionary project management(Evo) was
conceptualized by Thomas Gilb. Evo recommends one- to
two-week iterations, delivery of product each iteration
In 1986, “The New New Product Development Game,” a
whitepaper published by Takeuchi and Nonaka
Takeuchi and Nonaka discuss the “rugby approach” of
dedicated, self-organizing teams
www.izenbridge.com 4
5. “The… ‘relay race’ approach to product development…may
conflict with the goals of maximum speed and flexibility.
Instead a holistic or ‘rugby’ approach—where a team tries
to go the distance as a unit, passing the ball back and
forth—may better serve today’s competitive requirements.”
The New New Product Development Game
www.izenbridge.com 5
7. The 1990s saw a flurry of agile approaches
Scrum at Easel Corporation
Extreme Programming
Clear Crystal
IBM’s Rational Unified Process
Dynamic Systems Development Method (DSDM)
www.izenbridge.com 7
8. Agile software development is 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. It promotes adaptive planning,
evolutionary development and delivery, a time-boxed iterative
approach, and encourages rapid and flexible response to
change. It is a conceptual framework that promotes foreseen
interactions throughout the development cycle
www.izenbridge.com 8
9. In 2001, a group of 17
“lightweight”
methodologists met
Including Representative of
eXtreme Programming (XP)
Scrum
DSDM Adaptive Software
Development
Photo taken by Scott Catron
The Salt Lake Valley, The Agile Manifesto was
Snowbird, Utah written
www.izenbridge.com 9
10. 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.
www.izenbridge.com 10
11. Focus on empowered, self-managing teams;
Autonomous teams do not need the day-to-day intervention
of management
Management protects team from outside interference
Agile teams are composed of a mix of skills
Agile team members are able to step in for each other as
necessary
www.izenbridge.com 11
12. Traditionally we measure progress by the percent complete of
the functional milestones
Agile teams provide actual working product as a status
report, “product review”
Design changes as the system is built, results in outdated
documentation
Agile teams prefer face-to-face communication over
documentation because it is simpler, faster, and more
reliable.
www.izenbridge.com 12
13. Contract negotiation, Identify and define everything and
spells out the payment and date specifications
Customers become a part of the development process
Writing specs down and throwing them over the fence is
simply not effective
www.izenbridge.com 13
14. It’s much easier to respond to change when the organization
and the customer share a clear understanding of the
project’s status
In plan-driven environments, all requirements are specified
up front, broken down to the task level and estimated
Agile plans follow more of a rolling wave approach using top-
down planning
www.izenbridge.com 14
15. The empirical model of process control provides and exercises
control through frequent inspection and adaptation for
processes that are imperfectly defined and
generate unpredictable and unrepeatable outputs.
www.izenbridge.com 15
17. Empiricism asserts that knowledge comes from experience
and making decisions based on what is known.
Three pillars uphold every implementation of empirical
process control:
• Transparency
• Inspection
• Adaptation
www.izenbridge.com 17
28. Plan as you go Plan all in advance
Feature-breakdown Work-breakdown structure
structure Functional specs
User stories
Gantt chart
Status reports
Release plan Deliver at the end
Story boards Learn at the end
Deliver as you go Follow the plan
Learn every iteration Manage tasks
Adapt everything
Manage team
Agile : Iterative Traditional
www.izenbridge.com 28
30. Based On Adaptive Software Development (Highsmith 2000).
30
www.izenbridge.com
31. Envision: Determine the product vision and project objectives
and constraints, the project community, and how the team
will work together
Speculate: Develop a capability and/or feature-based release
plan to deliver on the vision
Explore: Plan and deliver running tested stories in a short
iteration, constantly seeking to reduce the risk and
uncertainty of the project
Adapt: Review the delivered results, the current situation,
and the team’s performance, and adapt as necessary
Close: Conclude the project, pass along key learning, and
celebrate.
www.izenbridge.com 31
32. What is the customer’s product vision?
What are the key capabilities required in the product?
What are the project’s business objectives?
What are the project’s quality objectives?
What are the project constraints (scope, schedule, cost)?
Who are the right participants to include in the project
community?
How will the team deliver the product (approach)?
www.izenbridge.com 32
33. Speculating establishes a target and a direction.
Speculating isn’t wild risk-taking but “conjecturing
something based on incomplete facts or information.”
The Speculate phase spotlights product and project.
Produce a refined list of scope items
Develop a Release
Develop detailed Iteration Plans for the next Iteration
www.izenbridge.com 33
34. Iteration Planning and Monitoring
Technical Practices
Project Community
www.izenbridge.com 34
35. A traditional project manager focuses on following the plan,
whereas an agile leader focuses on adapting successfully to
inevitable changes
Team has to answer critical questions
• Is value, in the form of a releasable product, being
delivered?
• Is the quality goal of building a reliable, adaptable product
being met?
• Is the project progressing satisfactorily within acceptable
constraints?
• Is the team adapting effectively to changes imposed by
management, customers, or technology?
www.izenbridge.com 35
36. Conduct the Project Closure , Pass along key learning and
celebrate.
www.izenbridge.com 36
38. Agile Development is Undisciplined
Agile Team do not plan
Agile Development is not Predictable
Agile Development does not scale
Agile means teams cannot be controlled by management
Agile means I can change my mind whenever I want to
Agile means you never have to write documentation
www.izenbridge.com 38
40. “Planning is everything. Plans are nothing.”
-Field Marshal Helmuth Graf von Moltke
www.izenbridge.com 40
41. If estimating and planning are difficult, and if it’s impossible to
get an accurate estimate until so late in a project, why do it at
all?
www.izenbridge.com 41
42. Reducing risk
Reducing uncertainty
Supporting better decision making
Establishing trust
Conveying information
www.izenbridge.com 42
43. Is focused more on the planning than on the plan
Encourages change
Results in plans that are easily changed
Is spread throughout the project
www.izenbridge.com 43
44. “No plan survives contact with the enemy.”
-Field Marshal Helmuth Graf von Moltke
www.izenbridge.com 44
45. Nearly two-thirds of projects significantly overrun their cost
estimates (Lederer and Prasad 1992)
Sixty-four percent of the features included in products are
rarely or never used (Johnson 2002)
The average project exceeds its schedule by 100% (Standish
2001)
www.izenbridge.com 45
46. Planning is by activity rather than feature
Features not prioritized
We ignore uncertainty
Estimates become commitments
www.izenbridge.com 46
47. “A good plan violently executed now is better than a perfect plan
executed next week.”
-General George S. Patton
www.izenbridge.com 47
48. Work as one team
Work in short iterations
Deliver something each iteration
Focus on business priorities
Inspect and adapt
www.izenbridge.com 48
49. Most Agile teams are concerned
only with the three innermost
levels
Release Planning
Iteration Planning
Day Planning
www.izenbridge.com 49
51. A user story describes functionality that will be valuable to
either a user or purchaser of a system or software.
www.izenbridge.com 51
52. Card:
Stories are traditionally written on note cards. Card may be
annotated with Notes , Estimates etc,
Conversation:
Details behind the story come out during conversations
with product owner.
Confirmation:
Acceptance tests confirms a story was coded correctly
www.izenbridge.com 52
53. Epic , Is a large User Story
Theme : A Collection of Related
User Stories
www.izenbridge.com 53
54. Independent
Negotiable
Valuable to users or customers
Estimatable
Small
Testable
www.izenbridge.com 54
55. Start with a Goal story
Monster.com User's Goal Is : Find a Job
• Search for jobs based on skill ,location , salary , Company
• Display resume to the Recruiters so that Recruiters can
search
• Easily apply for job
www.izenbridge.com 55
56. “A Job Seeker can post a resume”
Technical Division
• A Job Seeker can fill out a resume form.
• Information on a resume form is written to the database.
Slice the Cake
• A Job Seeker can submit a resume that includes only basic
information such as name, address, education history.
• A Job Seeker can submit a resume that includes all
information an employer may want to see.
www.izenbridge.com 56
57. “A recruiter can manage the ads she has placed.”
A recruiter can review resumes from applicants to one of her
ads.
A recruiter can change the expiration date of an ad.
A recruiter can delete an application that is not a good match
for a job.
www.izenbridge.com 57
59. Commonly used estimation units among agile team
Based on size and complexity of work
Unit-less but numerically relevant estimate
www.izenbridge.com 59
61. Forces the use of Relative estimating
It’s a Size estimation
Puts estimation in Unit which we can add together
www.izenbridge.com 61
62. Velocity is a measure of a team’s rate of progress.
Calculated by summing up all story points assigned to user
story that the team completed during iteration
www.izenbridge.com 62
63. The story being estimated is the only thing you’ll work on.
Everything you need will be on hand when you start.
There will be no interruptions.
www.izenbridge.com 63
64. Supporting the current release
Sick time
Meetings
Demonstrations
Personnel issues
Phone calls
Special projects
Training
Email
Reviews and walk-throughs
Interviewing candidates
Task switching
www.izenbridge.com 64
65. 1, 2, 3, 5, and 8
1, 2, 4, and 8
Epic / theme
• 13, 20, 40, and 100
www.izenbridge.com 65
67. 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
www.izenbridge.com 67
69. Timeboxing is setting a fixed time limit to overall
development effort and let other characteristics such as
scope vary.
Timeboxing Examples
• Iterations
• Daily Standups
www.izenbridge.com 69
70. Focus
Increased Productivity
Realization of Time Spent
Time Available
www.izenbridge.com 70
72. Release burndown chart
The vertical axis shows the number of story points remaining
in the project.
Iterations are shown across the horizontal axis.
A release burndown chart shows the amount of work
remaining at the start of each iteration.
www.izenbridge.com 72
75. It’s a concept related to Lean and Just In Time (JIT)
production
Kanban Boards shows current status of all the tasks need to
be done in current iteration, the tasks are represented by
cards, and the stauses are presented by area on the baord
separated and labeled.
Kanban boards helps the team in knowing how they are
doing and what to do next.
www.izenbridge.com 75