PMI-ACP Study Notes: Domain VII Continuous Improvement (Product, Process, People)

[NEW! For the 2015 July PMI-ACP® Exam syllabus] The PMI-ACP® Exam consists of 120 questions which can be categorised into seven domain. The Seventh domain: Domain VII Continuous Improvement (Product, Process, People) is the knowledge about “Continuously improving the quality, effectiveness, and value of the product, the process, and the team. ” (source: PMI-ACP® Examination Content Outline).

Domain VII Continuous Improvement (Product, Process, People) accounts for 9% of all questions in the PMI-ACP® Exam (i.e. ~11 questions among 120 PMI-ACP® Exam questions)

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 rooms 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 generalising specialists by providing learning and practising 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.

PMI-ACP® Study Notes: Domain VII Continuous Improvement (Product, Process, People)

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)
  • [usually for IT projects] 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 incompabitility
  • 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:
    1. A source code repository
    2. A check-out and check-in process
    3. 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
    • improve 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 next iteration and beyond without finger-pointing
  • typical agenda:
    1. set the stage – get people comfortable to speak and outline the topics for discussion
       • check-in – everyone express 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
    2. gather data
    3. generate insights
    4. decide what to do – identify the high priority items to devise an action plan
    5. 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 treated as non-functional backlogs
  • Retrospective Meeting vs Review Meeting
    • Retrospective meeting is for the development team only with the primary aim for process improvement
    • Review meeting is for demonstration / getting acceptance of deliverables with management, product owner and stakeholders
  • Retrospective Meeting vs Lessons Learned Meeting
    • 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 a feedback to the project itself)
• Intraspectives
  • intra = inside / within, (per)spective = a particular way of viewing things / inspection: intraspective =  inspecting within / seeing inwardly
  • intraspectives in Agile project management is an ad hoc discussion / meeting by the Agile team to review on 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
• Value Stream Mapping
  • [Agile principle] 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 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

Summary: Domain VII Continuous Improvement (Product, Process, People)

This PMI-ACP® Exam Study notes covers the seventh domain: Domain VII Continuous Improvement (Product, Process, People) of the new 2015 PMI-ACP® Exam syllabus. Domain VII accounts for 9% (~11 questions) of all questions to be found on the PMI-ACP® Exam.