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
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
9/6/19
3
Why Use Agile?
5
Why Use Agile?
6
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
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 ?
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
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
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
9/6/19
9
Scrum Pillars
17
Scrum Barstool
18
9/6/19
10
Scrum values
19
Core
Values
Commitment
Focus
OpennessRespect
Courage
Scrum Framework
20
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)
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
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
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
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
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
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
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
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
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
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
9/6/19
22
Generally Accepted Scrum Practices (GASPs)
43
• TDD
• Pair Programming
• Sprint 0
• Task boards
• Don’t Start on Monday
(should Wednesday)
• Backlog Grooming
• Definition of Ready
• …
SCRUM Summary
44
9/6/19
23
Scrum References
• https://www.scrumguides.org/
45
Large-Scale Scrum
9/6/19
24
Scrum of Scrums
47
Scrum of Scrums
48
9/6/19
25
Scrum of Scrums
49
1. https://less.works
Scrum of Scrums
50
2. SAFe = Shitty Agile Framework
9/6/19
26
Scrum of Scrums
51
3. Nexus
GAME
SCRUM ROLES
9/6/19
27
Scrum Roles and Responsibilities (20’)
53
# TASKS # TASKS
1 Ensure Quality 13 Improve technical practices
2 Attend Sprint Planning 14 Prioritise Product backlog
3 Attend Sprint Review 15 Talk tostakeholders
4 Attend Daily Standup 16 Track progress of thesprint
5 Attend Sprint Retrospective 17 Make Product Backlog visible toall
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 therelease
Product Owner
Ensure Quality
Scrum Master
Attend Sprint Review
Attend Daily Standup
DevelopmentTeam
Attend Daily Standup
Scrum Roles and Responsibilities (20’)
54
Requirement:
1. Discuss within yourteam.
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 OWNway.
4. Other team can give comment or “ném đá”.
9/6/19
28
Launching SCRUM
The Three Stages of Adoption
56
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
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
9/6/19
31
Adoption Strategies
61
XP (Extreme Programming)
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.
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.
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.
9/6/19
35
XP – Practices
69
Scrum & XP
70
9/6/19
36
XP Summary
71
Lean is mindset (not a methodology)
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
9/6/19
38
The Seven Wastes of Lean
75
Lean 5S Tool for Improvement
76
9/6/19
39
Lean – ThinkingTools
77
1. Seeing Waste 3. Queue Theory
2. Value Stream Mapping
1. 4. Pull Systems
2. 5. Option Thinking
3. 6. Cost of Delay
4. 7. Perceived/Conceptual Integrity
5. 8. Set-Based Development
6. 9. Measurements
7. - cycle time (working)
8. - lead time (working + waste)
Lean – Value Stream Mapping
78
9/6/19
40
Lean vs XP vs Scrum
79
KANBAN
9/6/19
41
Kanban – Principles and Practices
81
Kanban
82
9/6/19
42
The work items can be described in the form of cards
83
Kanban
84
9/6/19
43
Kanban – Cumulative flow diagram
85
Others
9/6/19
44
Crystal
87
Crystal
88
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
9/6/19
46
Feature Driven Development (FDD)
91
Comparison of Agile Frameworks
92
9/6/19
47
Agile Process Overview
[K&S] Agile Leadership
• Management versus Leadership
• Agile Leadership Practices
• Leadership Tasks
94
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
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
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
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
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
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
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

PMI-ACP: Domain I - Agile Principles and Mindset_v1.0

  • 1.
    9/6/19 1 MSc. PMP. NguyenThanh 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
  • 3.
  • 4.
    9/6/19 4 [K&S] The AgileMindset • 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 AgileTriangle [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 AgileManifesto • 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 notcontrol 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
  • 9.
  • 10.
  • 11.
    9/6/19 11 Scrum Framework 21 The ProductOwner 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 monthor 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 workto 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 SprintReview 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 Ø TheProduct 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 ScrumPractices (GASPs) 41 • 1. User stories and Story Points 2. Task Boards • 3. Planning Poker Generally Accepted Scrum Practices (GASPs) 42 • 4. Burndown chart
  • 22.
    9/6/19 22 Generally Accepted ScrumPractices (GASPs) 43 • TDD • Pair Programming • Sprint 0 • Task boards • Don’t Start on Monday (should Wednesday) • Backlog Grooming • Definition of Ready • … SCRUM Summary 44
  • 23.
  • 24.
  • 25.
    9/6/19 25 Scrum of Scrums 49 1.https://less.works Scrum of Scrums 50 2. SAFe = Shitty Agile Framework
  • 26.
    9/6/19 26 Scrum of Scrums 51 3.Nexus GAME SCRUM ROLES
  • 27.
    9/6/19 27 Scrum Roles andResponsibilities (20’) 53 # TASKS # TASKS 1 Ensure Quality 13 Improve technical practices 2 Attend Sprint Planning 14 Prioritise Product backlog 3 Attend Sprint Review 15 Talk tostakeholders 4 Attend Daily Standup 16 Track progress of thesprint 5 Attend Sprint Retrospective 17 Make Product Backlog visible toall 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 therelease Product Owner Ensure Quality Scrum Master Attend Sprint Review Attend Daily Standup DevelopmentTeam Attend Daily Standup Scrum Roles and Responsibilities (20’) 54 Requirement: 1. Discuss within yourteam. 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 OWNway. 4. Other team can give comment or “ném đá”.
  • 28.
  • 29.
    9/6/19 29 Apprentice • Adjusting toSprint 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
  • 31.
  • 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 – eXtremeProgramming 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.
  • 35.
  • 36.
    9/6/19 36 XP Summary 71 Lean ismindset (not a methodology)
  • 37.
    9/6/19 37 Lean Principles 73 1. Usingvisual 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
  • 38.
    9/6/19 38 The Seven Wastesof Lean 75 Lean 5S Tool for Improvement 76
  • 39.
    9/6/19 39 Lean – ThinkingTools 77 1.Seeing Waste 3. Queue Theory 2. Value Stream Mapping 1. 4. Pull Systems 2. 5. Option Thinking 3. 6. Cost of Delay 4. 7. Perceived/Conceptual Integrity 5. 8. Set-Based Development 6. 9. Measurements 7. - cycle time (working) 8. - lead time (working + waste) Lean – Value Stream Mapping 78
  • 40.
    9/6/19 40 Lean vs XPvs Scrum 79 KANBAN
  • 41.
    9/6/19 41 Kanban – Principlesand Practices 81 Kanban 82
  • 42.
    9/6/19 42 The work itemscan be described in the form of cards 83 Kanban 84
  • 43.
    9/6/19 43 Kanban – Cumulativeflow diagram 85 Others
  • 44.
  • 45.
    9/6/19 45 Crystal 89 Dynamic Systems DevelopmentMethod (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
  • 46.
    9/6/19 46 Feature Driven Development(FDD) 91 Comparison of Agile Frameworks 92
  • 47.
    9/6/19 47 Agile Process Overview [K&S]Agile Leadership • Management versus Leadership • Agile Leadership Practices • Leadership Tasks 94
  • 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 AgileMethods 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 ExamPrep 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 • Informationradiators 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