According to the PMI-ACP Exam Content Outline, Domain VII Continuous
Improvement (Product, Process, People) consists of 6 tasks:
1. Review product, processes, and practices periodically to look for
room for improvement and efficiency enhancement.
2. Conduct frequent retrospectives and experiments to continually
improve team processes and effectiveness.
3. Gather feedback from stakeholders on product increments and
demonstrations to enhance value delivery.
4. Develop a team of generalizing specialists by providing learning
and practicing opportunities.
5. Perform value stream analysis on existing processes to remove
wastes and improve efficiency.
6. Disseminate knowledge gained during carrying out the project
works to the whole organization for organizational improvement.
Below is a collection of the key knowledge addressed in Domain VII Continuous Improvement (Product, Process, People) and the 6 tasks related to the domain:
Integration, Testing, and Experiments
Continuous Integration (as a core practice in XP)
to continuously integrate changes (usually in small trunks) to the codebase by merging the new codes as soon as practicable (i.e. once ready)
to avoid code conflicts and minimize risks of incompatibility
on every integration, the codebase needs to be tested (usually by unit testing with automated testing tools/regression testing tools) typical setup for continuous integration:
A source code repository
A check-out and check-in process
An automated build process (compiles codes, runs tests, and deploys)
if errors are found, fixing the broken build is of top priority
Continuous Improvement
the Deming’s PDCA Cycle (plan – do – check -act)
make use of process improvement and self-assessment for improved product
e.g. code refactoring and pair programming
Testing (Exploratory and Usability)
Exploratory testing - seeks to find out how the software actually works, and to ask questions about how it will handle difficult and easy cases by asking test subjects to try the software
Usability testing - a special type of exploratory testing with emphasis on the usability of the software interface (whether the test subject will be able to perform core tasks on the interface without instructions and help) help to provide insights on the design of the software:
Users' expectations / habits
Users' ability to understand/comprehend the design of the interface Users' value of the functions of the software
both will provide valuable feedback early in the project to enhance value delivery and avoid failure later on
Learning Cycle
Agile software development is about learning - from little known about the end product in the beginning to (hopefully) delivering the maximal value in the end
understanding of the requirements as well as the technology to make the product feasible increase incrementally during the project
each retrospective/review is an opportunity to learn
it is recommended to keep learning cycles short so that new knowledge gained can be fed into the project as soon as possible
Review and Retrospective
Retrospective
an Agile process for self-evaluation to be performed at the end of each iteration (somehow similar to the "postmortem" meeting or "lessons learned" meeting in traditional project management)
a continuous process improvement for timely implementation
involved the Agile development team only with a timebox of up to 1 hour
a valuable learning opportunity for the Agile team
analyze, adapt and improve the entire development process improves productivity, capability, quality, and capacity
actionable improvement tasks are to be implemented right in the next iteration
for instant improvements
focus on what went well, what went wrong, and how the team can improve in the next iteration and beyond without finger-pointing typical agenda:
set the stage – get people comfortable to speak and outline the topics for discussion
check-in – everyone expresses in 1 or 2 words about the expectation of the retrospective
focus on / focus off – which side to focus on (e.g. dialogue vs debate)
ESVP – choose 1 from among “explorers, shoppers, vacationers and prisoners” that describes their feeling anonymously
working agreements – work on different topics in small groups first
gather data
generate insights
decide what to do – identify the high priority items to devise an action plan
close the retrospective – express appreciation and feelings
Plus / Delta – what should be done more / what should be changed Helped, Hindered, Hypothesis – three flip charts for participants to add ideas on
the improvement stories chosen in the retrospective will be treated as non-functional backlogs
Retrospective Meeting vs Review Meeting
The retrospective meeting is for the development team only with the primary aim for process improvement
The review meeting is for demonstration / getting acceptance of deliverables with management, product owner, and stakeholders
Retrospective Meeting vs Lessons Learned Meeting
The retrospective meeting is carried out once per iteration and identifies areas for improvement
Lessons Learned meeting is carried out once at the end of the project/phrase as the project closure activity and all the lessons learned are to be identified and documented (according to PMBOK Guide) for future references (not as feedback to the project itself)
Introspective
intra = inside / within, perspective = a particular way of viewing things / inspection: introspective = inspecting within / seeing inwardly introspective in Agile project management is an ad hoc discussion/meeting by the Agile team to review the team practices or teamwork during the sprint, often called for when something went wrong
Pre-mortem (rule setting, failure analysis)
A premortem is the hypothetical opposite of a postmortem in which team members are asked to generate plausible reasons for the project’s assumed failure.
To make it safe for team members to voice out their reservations about the plan/project direction / etc.
Can identify possible causes of failure which are missed during risk analysis
Value Stream Analysis and Mapping
The objectives of value stream analysis:
to provide optimum value flow to customers through value creation processes
by eliminating wastes in every process through analysis (e.g. value stream mapping) and enhancements
Simplicity – the art of maximizing the amount of work not done –is essential
Value stream mapping is originally a graphical tool for analyzing the flow of materials in manufacturing from its beginning through to the customer (e.g. in lean manufacturing).
It is later adopted for the value creation of services (e.g. IT development projects).
usually involves the following steps:
1. understand the current state (current state)
create a visual map of the value flow of the current state distinguish between value-adding processes and non-value-adding operations (including wastes)
find delays, wastes, and constraints
2. analyze and modify (the ideal future state)
create a new value stream map for the desired state after optimization (e.g. removing delays, wastes, and constraints)
3. communicate and carry out the improvements
ensure all team members understand the values of the improvement work
develop a roadmap for implementing the actions
4. verify and validate the improvements
All The Luck with your PMI-ACP Journey!