PMI-ACP: Domain I - Agile Principles and Mindset_v1.0
1. 9/6/19
1
MSc. PMP. Nguyen Thanh Phuoc
phuocnt@gmail.com
DOMAIN I
Agile Principles Mindset v1.0
Key Topics
• Agile frameworks and terminology
• Agile Manifesto
– 4 values
– 12 principles
• Agile methods and approaches
• Agile process overview
• Kanban
– Five principles
– Pull system
– WIP limits
• Leadership practices and principles
– Management vs. leadership
– Servant leadership (4 duties)
2
• Lean
– Core concepts
– 7 wastes
• Scrum
– Activities
– Artifacts
– Team roles
• XP
– Core practices
– Core values
– Team roles
2. 9/6/19
2
Tasks TO DO
1. Advocate for agile principles and values to create a shared
mindset
2. Ensure a common understanding of agile
3. Support change through educating and influencing
4. Practice transparency in order to enhance trust
5. Create a safe environment for experimentation
6. Experiment with new techniques and processes
7. Share knowledge through collaboration
8. Encourage emergent leadership via a safe environment
9. Practice servant leadership
3
Why Use Agile?
• Knowledge Work Project Are Different
• Defined versus Empirical Processes
4
4. 9/6/19
4
[K&S] The Agile Mindset
• Personal, Team and Organizational Agility
7
8
1. Increase return on investment by making continuous flow of
value our focus
2. Deliver reliable results by engaging customers infrequent
interactions and shared ownership
3. Expect uncertainty and manage for it through iterations,
anticipation, and adaptation
4. Unleash creativity and innovation by recognizing that
individuals are the ultimate source of value
5. Boost performance through group accountability for results
and shared responsibility for team effectiveness
6. Improve effectiveness and reliability through situationally
specific strategies, processes, and practices
General characteristics of the agile mindsetGeneral characteristics of the agile mindset
5. 9/6/19
5
9
• The Agile Triangle
[K&S] The Agile Mindset
“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.”
10
What is Agile ?
6. 9/6/19
6
[K&S] The Agile Manifesto
• The Four Values
11
q As described in the Agile Manifesto (http://www.agilemanifesto.org)
12 Principles in Agile
12
7. 9/6/19
7
[K&S] Agile Methodologies
• Scrum
• Extreme Programming (XP)
• Lean Product Development
• Kanban
• Feature-Driven Development (FDD)
• Dynamic Systems Development Method (DSDM)
• Crystal family methods
13
Generic flavor of Agile methodologies
14
8. 9/6/19
8
SCRUM
Ø 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
Scrum Framework
16
11. 9/6/19
11
Scrum Framework
21
The Product Owner
22
Ø 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)
12. 9/6/19
12
The Scrum Team
23
Ø 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 ProductOwner
Ø We can organize multiple teams working on
parallel Sprints
The Scrum Master
24
Ø 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
13. 9/6/19
13
The Scrum Master
25
Ø 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 externalinterferences
Ø Enforces the time-boxes
Ø Ensures that the process is followed by Product Owner,
Team Members, Stakeholders
Scrum Master vs Project Manager
26
14. 9/6/19
14
Ø 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
Scrum Events - Sprint
27
Ø Grooming the backlog
Scrum Events – Backlog Refinement
28
15. 9/6/19
15
Ø 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.
Scrum Events – Sprint Planning
29
Ø The Daily Scrum is a 15-minute time-boxedevent.
Ø During the meeting, the Development Team answer 3 questions:
Ø What did I do yesterday?
Ø What will I dotoday?
Ø Any impediments?
Scrum Events – Daily Scrum
30
16. 9/6/19
16
Ø 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
Scrum Events – Sprint Review
31
Ø 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.
Scrum Events – Sprint Retrospective
32
17. 9/6/19
17
Scrum Framework
33
Ø 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, andordering.
Ø 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.
Scrum Artifacts – ProductBacklog
34
18. 9/6/19
18
Scrum Artifacts – Product Backlog
35
Ø 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 ofwork.
Scrum Artifacts – SprintBacklog
36
19. 9/6/19
19
Scrum Artifacts – SprintBacklog
37
Ø Sum of all product backlog items completed to date.
Ø Must always be in a readily releasable (‘done’) state.
Scrum Artifacts –Increment
38
Iteration – n output
20. 9/6/19
20
Scrum Artifacts – Definition of“Done”
39
Code complete
Code reviewed
Unit tested
Integrated
Documented
No P1 defects, <3 P2 defects
Step 1. Create a “Definition of Done” which is as
comprehensive as possible The software produced at the end of
the Sprint would be ready to go live
Step 2. Now tick those items on the list which
are reasonable to do duringthe 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 postponingit until “later”?
Should be defined by all the Scrum Team
Scrum Artifacts – Definition of“Done”
40
21. 9/6/19
21
Generally Accepted Scrum Practices (GASPs)
41
• 1. User stories and Story Points 2. Task Boards
• 3. Planning Poker
Generally Accepted Scrum Practices (GASPs)
42
• 4. Burndown chart
29. 9/6/19
29
Apprentice
• Adjusting to Sprint Pacing
• Defining Done
• Daily Scrum Challenges
– Reporting to the ScrumMaster
– Not Reporting Impediments
– Lack of Focus on the Sprint Goal
– Replacing the Daily Scrum with a Tool
57
The Journeyman Stage
• Release Cycles
• Team Colocation
– Physical Arrangement
– Concerns
• Programmers (artists, designers, and so on) need to work in quiet
isolation to focus and be effective
• Release Dysfunctions
– difference between the definition of done for a sprint and the more
demanding definition of done for a release
– Hardening Sprint Used as a Dumping Ground
• Here are some warning signs that hardening sprints are being
abused (Programmers are deferring bug fixes; …)
– Postponed Value
– Improving Iteration
• Journeyman teams begin to accelerate the cycle of continuous
improvement by altering practices
58
30. 9/6/19
30
The Master Stage
• The master stage is the final stage of Scrum adoption and is
the goal of every Scrum team to achieve. Such teams do the
following:
– Self-organize
– Drive continual improvement
– Enjoy their work immensely
– Deliver the highest level of value
– Independence and a sense of ownership
– Leadership
– A core expert
– Team collaboration
– Proper studio culture
59
Adoption Strategies
60
32. 9/6/19
32
XP Core Values
63
1. Simplicity: This value focuses on reducing
complexity, extra features, and waste
2. Communication: This value focuses on
making sure all the tea members know what
is expected of them and what other people
are working on
3. Feedback: The team should get impressions
of suitability early. Failing fast can be useful
4. Courage: It takes courage to allow our work
to be entirely visible to others
5. Respect is essential on XP projects, where
people work together as a team and
everyone is accountable for the success or
failure of the project
XP – Lifecycle
64
Ø In XP – planning, analysis, design, coding, testing, deployment
are performed almost simultaneously and with rapid frequency.
33. 9/6/19
33
XP – eXtreme Programming
65
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 rules and 12 practices
XP – Lifecycle
66
Planning: (quaterly cycle)
Ø Clarifying the project vision, creating themes (to group stories together)
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
Ø Slack means giving the team some breathing room
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
reallly deployable.
Ø Coding standards are maintained.
Ø Encourages joint ownership of code, thus enabling anyone to fix any
defects in any part of the code.
34. 9/6/19
34
XP – Lifecycle
67
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.
XP – Roles
68
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. Note PMI - ACP => Tester
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.
37. 9/6/19
37
Lean Principles
73
1. Using visual management tools
2. Identifying customer-defined value
3. Building in learning and continuous improvement
The high-level lean principles listed above are common to Kanban
and all agile methods
Lean Core Concepts
74
45. 9/6/19
45
Crystal
89
Dynamic Systems Development Method (DSDM)
90
DSDM Principles:
1. Focus on the business need
2. Deliver on time
3. Collaborate
4. Never compromise quality
5. Build incrementally from firm
foundations
6. Develop iteratively
7. Communicate continuously and
clearly
8. Demonstrate control
48. 9/6/19
48
[T&T] Servant Leadership
• There are four primary duties a leader performs in this role of
serving the team
– Shield the team from interruptions
– Remove impediments to progress
– Communicate (and re-communicate) the project vision
– Carry food and water
95
[T&T] Servant Leadership
• Twelve Principles for Leading Agile Projects
1. Learn the team member’s needs
2. Learn the project’s requirements
3. Act for the simultaneous welfare of the team and the
project
4. Create an environment of functional accountability
5. Have a vision of the completed project
6. Use the project vision to drive your own behavior
7. Serve as the central figure in successful project team
development
96
49. 9/6/19
49
[T&T] Servant Leadership
• Twelve Principles for Leading Agile Projects (cont.)
8. Recognize team conflict as a positive step
9. Manage with an eye toward ethics
10. Remember that ethics is not an afterthought, but an
integral part of our thinking
11. Take time to reflect on the project
12. Develop the trick of thinking backwards
97
Agile Leadership Practices
• Model Desired Behavior
– Honesty
– Forward-looking
– Competent
– Inspiring
• Communicate the Project Vision
• Enable Others to Act
98
50. 9/6/19
50
Agile Leadership Practices
99
• Be Willing to Challenge the Status Quo
– We search for innovation ways to change, grow and improve
Leadership Tasks
• Practice Transparency through Visualization
• Create a Safe Environment for Experimentation
• Experiment with new Techniques and Processes
• Share Knowledge through Collaboration
• Encourage Emergent Leadership via a Safe
Environment
100
51. 9/6/19
51
Limitations of Agile Methods
1. difficult to provide an estimate
2. ‘daily’ collaboration with users
3. make it hard for specialists and new joiners
4. tendency to avoid documentation altogether è create a challenge
for knowledge retention and ongoing support and maintenance of
the project
5. take hasty decisions without a thorough analysis è This could lead
to considerable rework and potential increase of costs
6. testers are kept busy throughout the project
7. Agile projects are intense with lot of timeboxed activities to
accomplish in a short iteration
8. sophisticated technology tools that do automated testing, version
management, continuous build and integration and automated
release management
101
Chapter review by Quizziz CODE
• Agile frameworks and terminology
• Agile Manifesto
– 4 values
– 12 principles
• Agile methods and approaches
• Agile process overview
• Kanban
– Five principles
– Pull system
– WIP limits
• Leadership practices and principles
– Management vs. leadership
– Servant leadership (4 duties)
102
• Lean
– Core concepts
– 7 wastes
• Scrum
– Activities
– Artifacts
– Team roles
• XP
– Core practices
– Core values
– Team roles
52. 9/6/19
52
References
• PMI-ACP Exam Prep 2015 By Mike Griffiths, PMI-ACP, PMP
• Many other resources from Internet
103
Thank you for your attention!
phuocnt@gmail.com
104
53. 9/6/19
53
Information Radiators
• Information radiators are highly visible charts and figures
displaying project progress and status, e.g. Kanban boards,
burn-down charts. These shows the real progress and
performance of the project and team which enhances
transparency and trust among team members and other
stakeholders.
105
Agile Experimentations
• Agile projects make use of empirical process control for project
decisions, ongoing observation and experimentation are carried
out during project execution to help and influence planning
• Introduce spike (including architecture spike) to carry out a
technical investigation to reduce risks by failing fast
106
54. 9/6/19
54
Sharing of Knowledge
• Ideally, Agile teams are best to be co-located (working within the
same room with seats facing each other) to enhance pro-active
support, free discussion, open collaboration and osmotic
communication
• Face-to-face communication is always encouraged
• Practice pair programming if feasible
• Make use of daily stand-up, review and retrospectives
• Make use of Agile tooling to enhance sharing of knowledge:
– Kanban boards
– white boards
– bulletin boards
– burn-down/burn-up charts
– wikis website
– instant messaging – Skype, web conferencing, etc.
– online planning poker
• Since documentations are not encouraged, co-located teams can
share tacit (không thể nói hết) knowledge more readily
107
Self-organization and Empowerment
• Self-organizing teams are the foundation for Agile project
management Self organization includes: team formation, work
allocation (members are encouraged to take up works beyond
their expertise), self management, self correction and
determining how to work is considered “done”
• Agile team is given the power to self-direct and self-organize by
making and implementing decisions, including: work priority, time
frames, etc. as they believe “the best person to make the decision
is the one whose hands are actually doing the work”
• In Agile projects, the project manager/Coach/ScrumMaster
practice servant leadership to remove roadblocks and obstacles
and to enable the team to perform best
108