This is the first lesson of our 15 lesson series of PMI-ACP Program.

1. Agile Framework
Saket Bansal
PMP, PMI-ACP , CSM , ITIL V3 F
www.izenbridge.com 1

2.  Essence of Agile
 Agile Values and Principles
 Overview of Agile Methods
 Agile and Traditional Development Methodology
 APM (Agile Project Management Framework)
2
www.izenbridge.com

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

6. Source: Wikipedia-Photo taken by Maree Reveley (aka Somerslea)
www.izenbridge.com 6

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.
The meeting also included the
representatives 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 amalgamation of varied professional 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 which 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

16. www.izenbridge.com 16

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

18. Agile Principles
www.izenbridge.com 18

19.  Our highest priority is to satisfy the customer through early
and continuous delivery of valuable software.
 Welcome changing requirements, even late in development.
Agile processes harness change for the customer’s
competitive advantage.
 Deliver working software frequently, from a couple of weeks
to a couple of months, with a preference to the shorter
timescale
 Business people and developers must work together daily
throughout the project.
www.izenbridge.com 19

20.  Build projects around motivated individuals. Give them the
environment and support they need, and trust them to get
the job done
 The most efficient and effective method of conveying
information to and within a development team is face-to-face
conversation.
 Working software is the primary measure of progress.
 Agile processes promote sustainable development. The
sponsors, developers, and users should be able to maintain a
constant pace indefinitely.
www.izenbridge.com 20

21.  Continuous attention to technical excellence and good design
enhances agility
 Simplicity—the art of maximizing the amount of work not
done—is essential.
 The best architectures, requirements, and designs emerge
from self-organizing teams.
 At regular intervals, the team reflects on how to become more
effective, then tunes and adjusts its behavior accordingly.
www.izenbridge.com 21

22.  We increase return on investment by making continuous flow
of value our focus.
 We deliver reliable results by engaging customers in frequent
interactions and shared ownership.
 We expect uncertainty and manage for it through iterations,
anticipation, and adaptation.
 We unleash creativity and innovation by recognizing that
individuals are the ultimate source of value, and creating an
environment where they can make a difference.
 We boost performance through group accountability for
results and shared responsibility for team effectiveness.
 We improve effectiveness and reliability through situational
specific strategies, processes and practices.
www.izenbridge.com 22

23. Agile Methods
www.izenbridge.com 23

24.  Phases
Inception, Elaboration, Construction, Transition
 Disciplines
Model, Implementation, Test, Deployment, Configuration
Management, Project Management, Environment
 Philosophies
Your staff knows what they're doing, Simplicity, Agility,
Focus on high-value activities, Tool independence, You'll
want to tailor the AUP to meet your own needs
www.izenbridge.com 24

25.  Frequent Delivery of Usable Code to Users (required)
 Reflective Improvement (required)
 Osmotic Communication Preferably by Being Co-Located
(required)
 Personal Safety
 Focus
 Easy Access to Expert Users
 Automated Tests, Configuration Management, and Frequent
Integration
www.izenbridge.com 25

26.  Principles
• User involvement is the main key, The project team must
be empowered, Frequent delivery of products, Delivering a
system that addresses the current business needs,
Development is iterative and incremental, Changes are
reversible, High level scope and requirements should be
base-lined, Testing is carried out throughout the project
life-cycle, Communication and cooperation among all
project stakeholders
 Techniques
• Timeboxing, MoSCoW, Prototyping, Testing, Workshop,
Modelling
www.izenbridge.com 26

27.  Values
• Communication, Simplicity, Feedback, Courage, Respect
 Activities
• Coding, Testing, Listening, Designing
 Practices
• Pair programming, Planning Game, Test Driven
Development, Whole team, Continuous Integration, Design
Improvement, Small Releases, Coding Standards, Collective
Code Ownership, Simple Design, System Metaphor,
Sustainable Pace
www.izenbridge.com 27

28.  Activities
• Develop Overall Model, Build Feature List, Plan By Feature,
Design By Feature, Build By Feature, Milestones
 Best practices
• Domain Object Modelling
• Developing by Feature
• Individual Class (Code) Ownership
• Feature Teams
• Inspections
• Configuration Management
• Regular Builds
• Visibility of progress and results
www.izenbridge.com 28

29.  Scrum Team
 Events
• Sprints
• Sprint Planning Meeting
• Sprint Review Meeting
• Daily Scrum
• Sprint Review Meeting
• Sprint Retrospectives
 Artifacts
• Product Backlog
• Sprint Backlog
www.izenbridge.com 29

30. Agile Vs. Traditional
www.izenbridge.com 30

31. A project is still a project:
• Vision
• Life cycle
• Requirements
• Schedule
• Team
• Communication mechanisms
www.izenbridge.com 31

32. Waterfall Model Agile Project Life Cycle
www.izenbridge.com 32

33. www.izenbridge.com 33

34.  Plan all in advance  Plan as you go
 Work-breakdown  Feature-breakdown
structure structure
 Functional specs  User stories
 Gantt chart
 Release plan
 Status reports
 Deliver at the end  Story boards
 Learn at the end  Deliver as you go
 Follow the plan  Learn every iteration ,
Adapt
 Manage tasks  Manage team
Agile : Iterative
Traditional
www.izenbridge.com 34

35. Agile Project Management Framework
www.izenbridge.com 35

36. Based On Adaptive Software Development (Highsmith 2000).
www.izenbridge.com 36

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

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

39.  The elevator test statement—an explanation of the project to
someone within two minutes—takes the following format:
 For (target customer)
 Who (statement of the need or opportunity)
 The (product name) is a (product category)
 That (key benefit, compelling reason to buy)
 Unlike (primary competitive alternative)
 Our product (statement of primary differentiation)
www.izenbridge.com 39

40.  Clients/customers  Exploration factor
 Project leader  Delay cost
 Product manager  Capabilities
 Quality Objectives
 Executive Sponsor
 Performance/quality
 Project Objective Statement attributes
 Business Objectives  Architectural Guidelines
 Tradeoff matrix  Issues/risks
www.izenbridge.com 40

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

42.  Product Backlog
• The objective of creating a product backlog is to expand
the product vision, through an evolutionary requirements
definition process, into a product feature list, or backlog.
 Release Planning
• A release plan presents a roadmap of how the team intends
to achieve the product vision within the project objectives
and constraints identified in the project data sheet
www.izenbridge.com 42

43.  Iteration 0 helps teams balance anticipation with
adaptation.
 The “0” implies that nothing useful to the customer—stories,
in other words—gets delivered in this time period. However,
the work is useful to the team.
www.izenbridge.com 43

44. www.izenbridge.com 44

45.  Iteration Planning and Monitoring
 Technical Practices
 Project Community
www.izenbridge.com 45

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

47. Conduct the Project Closure , Pass along key learning and
celebrate.
www.izenbridge.com 47

48. Saket Bansal
Saket.Bansal@iZenBridge.com
M: 9910802561
Web: www.iZenBridge.com
Twitter: Saket_tg
LinkedIn: www.linkedin.com/in/saketbansal
www.izenbridge.com 48