PMI – ACP

1- Agile Principles and Mindset

February 19, 2016 1
 Agenda
1. Agile Introduction
2. Scrum
3. XP – eXtreme Programming
4. Lean
5. Kanban
6. Crystal
7. DSDM
8. Feature Driven Development (FDD)
9. Q&A Session

2
 Agile is the Mindset

Agile people need to turn their

thinking upside down

3
 What is Agility
Agility is the ability to deliver customer value while dealing
with inherent project unpredictability and dynamism by
recognizing and adapting to change

üAgility is the capability to balance

• Stability with flexibility
• Order with chaos
• Planning with execution
• Optimization with exploration
• Control with speed
ü…to deliver customer value reliably in the face of uncertainty
and change

4
 What is Agile
“Agile is a time boxed, iterative approach to software delivery that builds
software incrementally from the start of the project, instead of trying to deliver it
all at once near the end.”

5
 Agile Manifesto
q As described in the Agile Manifesto (http://www.agilemanifesto.org)

6
Agile Principles

7
Agile Performance Measurement

8
Agile Frameworks

9
Comparison of Agile Frameworks

10
SCRUM

11
 Today Software Development

Ø Today's users change their minds about needs and

desires minute to minute
Ø Developers continuously release new technologies and
better versions of the old
Ø A change in one means a change in the other
Ø Software development is more complex for traditional
approach

12
 Scrum Framework

Ø Do not control complex projects by acting as task masters and

telling everyone what to do every day

Ø Control -> allowing a team to self manage through a series of sprints

(time-boxes)

Ø Define roles which have specific and important set of

responsibilities, each steeped in the idea of controlling chaos

Ø Each sprint, an empowered team focuses on a narrow selection of

product backlog (in order) and devises the appropriate technical
solution bit by bit

Ø Make the project to the simple range of sprint after sprint

13
Scrum Framework

14
Scrum Barstool
15
Scrum core values

Commitment

Courage Focus

Core
Values

Respect Openness

16
SCRUM ROLES

17
 The Product Owner
Ø Responsible for:
Ø Maximizing return on investment (ROI)
Ø Identifying product features, translating these
into a prioritized list, deciding which should be
at the top of the list
Ø Continually re-prioritizing and refining the list
Ø Working with Scrum teams to clarify
everything
Ø Accepts or rejects work results
Ø Part of Scrum important role during Sprint
Planning
Ø The Product Owner (typically someone from a
Marketing role or a key user in internal
development)

18
 The Scrum Team

Ø Usually small team(s) (5 to 9 people) that “build”

product
Ø “Cross-functional” and “self-managing” team
Ø Need to work closely with Product Owner
Ø Make decision for what to commit to Sprints
Ø Should be 100% dedicated to Sprint
Ø Reviews work results with the Product Owner
Ø We can organize multiple teams working on
parallel Sprints

19
The Scrum Team

Technical
Lead

CM /
Architect
Release

Scrum
Team
UI / UX Developer

Tester

20
The Scrum Master

21
 The Scrum Master

Ø Just to help the Team be successful

Ø Addresses issue and threats to effectiveness
Ø Responsible for Sprint Demonstration and
meetings
Ø Maintains the issue List and ensures task
board and burn-down chart are accurate
Ø Calculates and enforces team commitment
velocity
Ø Ensures the Product Owner is ready for the
next Sprint Planning Meeting

22
 The Scrum Master

Ø Not a PM or team lead, does NOT “manage” the Scrum

team and work as full-time role
Ø Does not assign tasks or tell people what to do
Facilitates and supports the team as it manages itself
Ø Shields the team from external interferences
Ø Enforces the time-boxes
Ø Ensures that the process is followed by Product Owner,
Team Members, Stakeholders

23
Scrum Master vs Project Manager

24
SCRUM EVENTS

25
 Scrum Events - Sprint

Ø One month or less

Ø Creates potentially releasable product increment
Ø Scope fixed for the duration
Ø No CHANGE allowed!
Ø Product Owner may cancel a Sprint
Ø Includes the Events: Sprint Planning Meeting, Daily Scrums,
Development Work, Sprint Review and Retrospective

26
 Scrum Events – Sprint Planning

Ø The work to be performed in the Sprint is planned at the Sprint

Planning. This plan is created by the collaborative work of the entire
Scrum Team.
Ø Sprint Planning is time-boxed to a maximum of 8 hours for a one-
month Sprint. For shorter Sprints, the event is usually shorter.
Ø Sprint Planning answers the following:
Ø What can be delivered in the Increment resulting from the
upcoming Sprint?
Ø How will the work needed to deliver the Increment be achieved?
Ø The Sprint Goal is an objective set for the Sprint that can be met
through the implementation of Product Backlog.

27
 Scrum Events – Daily Scrum

Ø The Daily Scrum is a 15-minute time-boxed event.

Ø During the meeting, the Development Team answer 3 questions:
Ø What did I do yesterday?
Ø What will I do today?
Ø Any impediments?

28
 Scrum Events – Sprint Review

Ø A Sprint Review is held at the end of the Sprint to inspect the

Increment and adapt the Product Backlog if needed.
Ø 4 hours time-boxed meeting for one-month Sprints.
Ø The Sprint Review includes the following elements:
Ø The Product Owner explains what Product Backlog items have
been “Done” and what has not been “Done”;
Ø The Development Team discusses what went well during the
Sprint, what problems it ran into, and how those problems were
solved;
Ø The Development Team demonstrates the work that it has
“Done” and answers questions about the Increment;

Ø Output: Revised Product Backlog

29
 Scrum Events – Sprint Retrospective
Ø The Sprint Retrospective is an opportunity for the Scrum Team to
inspect itself and create a plan for improvements to be enacted
during the next Sprint.
Ø 3 hours time-boxed meeting for one-month Sprints.
Ø The purpose of the Sprint Retrospective is to:
Ø Inspect how the last Sprint went with regards to people,
relationships, process, and tools;
Ø Identify and order the major items that went well and potential
improvements; and,
Ø Create a plan for implementing improvements to the way the
Scrum Team does its work.

30
 Scrum Artifacts – Product Backlog
Ø The Product Backlog is an ordered list of everything that might be
needed in the product.
Ø The single source of requirements for any changes to be made to
the product.
Ø The Product Owner is responsible for the Product Backlog, including
its content, availability, and ordering.
Ø The Product Backlog is dynamic.
Ø The Product Backlog lists all features, functions, requirements,
enhancements, and fixes.
Ø Product Owner collects all the ideas, inputs from Development team,
Stakesholders to build the Product Backlog.

31
 Scrum Artifacts – Sprint Backlog
Ø Is the set of Product Backlog items selected for the Sprint.
Ø Makes visible all of the work that the Development Team identifies
as necessary to meet the Sprint Goal.
Ø Provides enough detail for tracking during daily scrum.
Ø Only development team can update and make changes.
Ø Highly visible; show the real time picture of work.

32
 Scrum Artifacts – Increment
Ø Sum of all product backlog items completed to date.
Ø Must always be in a readily releasable (‘done’) state.

Iteration – n output

33
 Scrum Artifacts – Definition of “Done”

Code complete
Should be defined by all the Scrum Team
Code reviewed
Unit tested Step 1. Create a “Definition of Done” which is as
Integrated comprehensive as possible The software produced at the end of
Documented the Sprint would be ready to go live
Step 2. Now tick those items on the list which
are reasonable to do during the Sprint
In other words, a “Definition of Done” that is doable.
Everything not ticked will be done “later”
Step 3. For each item not ticked, what will be
the possible / probably negative consequence
of postponing it until “later”?

No P1 defects, <3 P2 defects

34
Scrum Artifacts – Definition of “Done”

35
Scrum Framework

36
 GAME:
Scrum Roles

37
 Scrum Roles and Responsibilities (20’)

# TASKS # TASKS
1 Ensure Quality 13 Improve technical practices
2 Attend Sprint Planning 14 Prioritise Product backlog
3 Attend Sprint Review 15 Talk to stakeholders
4 Attend Daily Standup 16 Track progress of the sprint
5 Attend Sprint Retrospective 17 Make Product Backlog visible to all
6 Attend Backlog Refinement Meeting 18 Create Product backlog items
7 Design 19 Resolve Technical impediments
8 Build 20 Resolve organizational impediments
9 Test 21 Facilitate Scrum events
10 Integrate software 22 Ensure Scrum rules are followed
11 Deploy 23 Coach team
12 Improve process 24 Track progress of the release

38
Scrum Roles and Responsibilities (20’)

Requirement:
1. Discuss within your team.
2. Pick up the right tasks to assign to right Role.
• One task can be assigned to multiple Roles.
3. Present your results (10 minutes / 1 team) by your OWN way.
4. Other team can give comment or “ném đá”.

Product Owner Scrum Master Development Team

Ensure Quality Attend Sprint Review Attend Daily Standup

Attend Daily Standup

39
XP – eXtreme Programming

40
 XP – eXtreme Programming

This is a software development methodology that is based on values and

practices that the teams follow to provide short increments of a product.

Ø Delivers business value to the customer early and frequently

Ø Improves productivity
Ø Embraces change
Ø XP contains 3 roles, 5 alues and 12 practices

41
 XP – eXtreme Programming
Roles:
Ø Customer
Ø Programmer
Ø Coach

Values:
Ø Courage
Ø Communication
Ø Simplicity
Ø Feedback
Ø Respect

Practices:
Ø 12 listed

42
 XP – Lifecycle
Ø In XP – planning, analysis, design, coding, testing, deployment
are performed almost simultaneously and with rapid frequency.

Planning

Deployment Analysis

Testing Design

Coding

43
 XP – Lifecycle
Planning:
Ø Clarifying the project vision, creating user stories, constructing a release
plan and managing risks.
Ø Planning game – where customers prioritize work with team inputs
Ø Creation of detailed plan for the upcoming iteration

Analysis:
Ø Onsite customers sit with the team full time and help in creating user
stories and customer acceptance tests.

Design and Code:

Ø Use Test Driven Development (TDD) to do incremental design and
architecture, which also leads to tested code.
Ø Programmers integrate their tested code every few hours to keep the code
reaily deployable.
Ø Coding standards are maintained.
Ø Encourages joint ownership of code, thus enabling anyone to fix any
defects in any part of the code.

44
 XP – Lifecycle
Testing:
Ø TDD results in automated unit, integration and end-to-end tests.
Ø Automated customer acceptance tests ensure that code matches
customers intent.
Ø Exploratory testing by testers looks for gaps in the software code.
Ø The full suite of automated tests are run every time code is integrated.
Ø XP further supports quality through pair programming, energized work and
iteration slack.

Deployment:
Ø In XP, software is ready to deploy at the end of any iteration.

45
 XP – Roles
Customer:
Ø The product owner, who defines the goals of the project, makes business
decisions, prioritied work, writes stories, and acceptance tests. Works with
the development team.

Coach:
Ø The person who guides and manages the project team (called the “Whole
Team”).

Whole Team:
Ø The team members developing the product. This is a generic term used to
imply coders, testers, designers, and other subject matter experts (SMEs).
Their role is to work together in creating an increment of delivery.

46
XP – Values

47
XP – Practices

48
Lean

49
Lean

50
Lean - Principles

51
Lean - Principles

52
Lean - Principles

53
Lean - Tools

54
Lean – Value Stream Mapping

55
Kanban

56
 Kanban

Ø Task Kanban Board named after Just-In-Time production method in

Toyota Production System (TPS).
Ø A Kanban is a ticket describing a task to do.

57
Kanban

58
 Kanban – Limiting Work in Progress (WIP)

Ø Contribute to faster completion, better quality, and greater focus on

only the highest-priority work.
Ø A WIP limit is a policy, an agreed-upon decision about how the work
will be processed.
Ø A WIP limit defines a stage in the Kanban system.

59
 Kanban – Principles and Practices

3 Principles of Kanban:
Ø Start with what you know
Ø Agree to pursue incremental, evolutionary change
Ø Initially, respect current roles, responsibilities and job titles

Kanban 5 Core Practices:

Ø Visualize
Ø Limiting work in progress
Ø Manage flow
Ø Make management policies
Ø Improve collaboratively using “safe to fail” experiments

60
Crystal

61
Crystal

62
Dynamic Systems Development Method
(DSDM)

63
DSDM

64
Feature Driven Development
(FDD)

65
FDD

66
CONCLUSION

67
Conclusion

68
LESSON QUIZ

69
 Lesson Quiz

In the Agile Manifesto, what is over than Processes and Tools?

a. Customer collaboration
b. Individuals and interactions
c. Working software
d. Responding to change

Correct Answer is B.

70
 Lesson Quiz

Which of the following is NOT a characteristic of Agile project

management when compared with waterfall management?

a. Time-boxed delivery
b. Focus on customer satisfaction
c. Top-down control
d. Value-focused metrics

Correct Answer is C.
Top down control is not a characteristic of Agile project management whereas self
organizing teams is a characteristic of Agile project teams.

71
 Lesson Quiz

Which of the following is a lightweight approach to Agile?

a. Lean
b. Agile unified process
c. DSDM
d. Crystal

Correct Answer is A. Lean is a lightweight approach to Agile.

72
 Lesson Quiz

The Scrum Team consist of the following:

a. The Product Owner, Scrum Master, and the Team.

b. The Scrum Master, Product Owner, the stakeholders, and the Team.
c. The Project Manager, Scrum Master, Product Owner and the Team.
d. The Scrum Master, Product Owner, and the Project Manager.

Correct Answer is A.

73
74