Continuous Improvement (Domain VII) contains the focus areas & quick notes on this topic which will help you to pass the PMI-ACP® exam offered by PMI. Domain VII Continuous Improvement (Product, Process, People) accounts for 9% of all questions in the Exam (i.e. ~11 questions among 120 Exam questions). Below is a collection of the key knowledge addressed in Continuous Improvement and the tasks related to the domain:
Focus Areas for Continuous Improvement
Product improvement
- Continuous Integration.
- Continuous Improvement: PDCA Cycle (Plan – Do – Check -Act), code refactoring, and pair programming.
- Dissemination of knowledge.
Process improvement
- Kaizen: Kaizen is the practice of continuous improvement. The Japanese word Kaizen is a combination of two words Kai and Zen, which means to change for the better.
- Process analysis: Improving efficiency and effectiveness of processes by identifying and removing overheads, constraints, or anything that does not add value.
- Lean 5S technique: The acronym 5S stands for sort, set in order, shine, standardize and sustain. The goal of this technique is to remove waste materials from the workspace, keep it clean periodically and follow standardized processes to facilitate a smooth flow.
- Kanban Kata: Kanban Kata is another continuous improvement strategy that uses a series of questions to help improve in small steps such that day-to-day work and improvements happen simultaneously. A set of Kata questions could look as follows:
- Q1: What is the target state that we are trying to achieve?
- Q2: What is the current state?
- Q3: What are the impediments or blockers on the way?
- Q4: What is the next step to resolve the impediment?
- Q5: When can we see what we learned from taking that step?
- 5 Why’s technique: The 5 Why’s technique is used by teams to identify the root cause of a particular problem by asking a series of ‘why’ questions. The questions explore the cause-and-effect relationships between observations.
- Fishbone diagram: The fishbone diagram, also called the Ishikawa diagram, is an extension of the 5 why’s technique to determine the root cause of a problem. It asks a series of questions to explore cause-effect relationships until the addressable root cause is determined.
- Pareto Diagrams (80-20 rule): The Pareto principle, also called the 80-20 rule is based on measuring the frequencies or occurrences that cause most of the problems. The rules state that 80% of the problems are due to 20% of the causes. Alternatively stated, 80% of the system errors can be removed by resolving 20% of the defects.
- Control charts: This is used to determine whether the performance of a process is within the expected range demarcated by upper and lower limits. Usually, the upper and lower limits are specified at a three-sigma value (sigma is the standard deviation) on either side of the mean.
Review and Retrospective
- Focus on what went well, what went wrong, and how the team can improve in the next iteration.
- Steps: Set the stage to Gather data, Generate insights, Decide what to do Closing
- SAMOLO – Same as – more or – less of Same as’ are those processes and practices that the team finds value and would continue to use. ‘More of’ are those processes and practices that the team finds value, in but feels it’s not doing enough of. ‘Less of’ are those processes and practices that a team starts finding diminishing value and would like to discourage.
- Start doing – stop doing – keep doing: ‘Start doing’ are the activities that the team feels are not done, but are worth doing because they will generate better outcomes. ‘Stop doing’ are the activities that the team feels are not useful, generally disliked, or not worth doing, so should be stopped. ‘Keep doing’ are the activities that are liked, add value and the team feels are worth continuing.
- Lessons learned vs retrospectives
- A 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/phase as the project closure activity and all the lessons learned are to be identified and documented for future references (not as feedback to the project itself).
- Retrospective Meeting vs Review Meeting
- A retrospective meeting is for the development team only with the primary aim for process improvement.
- A review meeting is for demonstration / getting acceptance of deliverables with management, product owner, and stakeholders.
Premortem / pre-failure analysis
Pre-mortems are logically opposite to retrospectives that are conducted after the iteration. In a premortem, the team members are asked to determine possible reasons for what can go wrong or why the project could fail in the future.
Agile adoption
- Agile hybrid models: a model that is more of a hybrid between traditional waterfall and Agile approaches. Suitable for Large multi-year complex programs, Regulatory and compliance projects, etc.
- Sidky Agile Maturity Index: SAMI is used to rank the maturity of Agile practices in an organization. There are five levels: Collaborative, Evolutionary, Integrated, Adaptive, and Encompassing.
- Virginia Satir change model: organizations and teams go through the change curve when they transition from traditional methodologies to Agile. There could be a dip in performance for a little time, as the teams organize themselves, therefore looking to overcome resistance to change and settle down into a sustainable operating rhythm.
