PMI-ACP Tools and Techniques: Planning, Monitoring, And Adapting

[PMI-ACP® Exam Study Notes] Planning, Monitoring, And Adapting is one of the ten Tools and Techniques for the PMI-ACP® exam. The “Tools and Techniques” accounts for a total of 50% of all the questions to be found on the exam paper. According to the PMI-ACP® exam content outline, Planning, Monitoring, And Adapting includes retrospectives, task/Kanban boards, timeboxing, iteration and release planning, WIP limits, burn-down/up charts, cumulative flow diagrams and process tailoring.

PMI-ACP® Exam Importance: around 3-6 questions (~5% of all questions)

PMI-ACP® Tools and Techniques: Planning, Monitoring, And Adapting

• Unlike the traditional project management triangle of “Time, Cost and Functionality (Scope)“, the inverted triangle model for Agile projects includes “Resources, Time and Functionality (Scope)”. [bold indicates fixed] 
• The agile project management phases are: envisioning, speculating, exploring, adapting, closing.
• Agile Planning (Deming Cycle – Plan of PDCA)
  • plan at different levels with stakeholder engagements
  • central to Agile project success (though Agile project are not plan-driven, there are plans for every release, sprint and even work day)
    • replanning and midcourse adjustments are the norm
    • less planning upfront to strike a balance of balancing risks and planning investments
  • just-in-time planning as the project is ever evolving using rolling wave planning, progressive elaboration techniques
  • Agile Planning Stages (Iterative in nature)
    1. Product Vision – [revised once a year] a document created by product owner describing what the product is, who will and why use it, and how the product supports company strategy
    2. Product Roadmap – [revised twice a year] a document created by product owner describing the high-level product requirements, timeframes for deliverables, prioritization and estimations, it is a visual overview of all the releases and major components
       • can be in the form of story maps – a diagram indicating the sequences of backbone, walking skeleton and optional features to be released over time
       • then the features to be release in the 1st, 2nd, 3rd, etc. releases can be mapped out
    3. Release Plan – [revised twice / four times a year] a document created by product owner describing the high-level timeline for product releases (features with higher values are given higher priority in the releases)
    4. Sprint Plan / Iteration Plan – [revised once a month / an iteration] a document created by product owner, scrum master and development team describing sprint goals and requirements and how those requirements will be completed
    5. Daily Stand-up / Daily Scrum – [daily for 15 minutes] a meeting to be attended by project team and stakeholders to discuss on what was completed yesterday, what will be done today and any roadblocks found
    6. Sprint Review – [monthly, at least an hour, for scrum] a meeting at the end of each sprint to demonstrate the working product/deliverable to stakeholders for feedback/acceptance
    7. Sprint Retrospective – [monthly, at least an hour, for scrum] a meeting at the end of each sprint to discuss on product and process improvements, at least one area is picked to focus on continuous improvement
• Agile Monitoring (Deming Cycle – Check of PDCA)
  • unlike the “monitoring and control” of traditional project management to avoid deviation from the plan, Agile monitoring is more about inspection for values and processes for the project, every release, every sprint and every day
  • Agile monitoring involves Agile metrics/measurements, variances, and burn-up and burn-down charts, change management, forecasting, continuous improvements, retrospectives, quality control, frequent validation and verifications and other related activities
• Agile Adapting (Deming Cycle – Act of PDCA)
  • Agile adapting is essentially making changes to the project, product and processes for implementing changes which customers value most
  • Agile adapting involves process tailoring, continuous integration, adaptive leadership, soft skills negotiations, delivering business value, revised vendor management, change management

Planning, Monitoring, And Adapting Tools and Techniques

• Retrospective
  • an Agile process for self-evaluation (similar to a “postmortem” meeting or “lessons learned” meeting in traditional project management) by the Agile development team only to analyze, adapt and improve the entire Agile development performance – a learning opportunity for the Agile team and the project
    • improve productivity, capability, quality and capacity
  • lessons learned are to be implemented by the Agile team right in the next iteration for instant improvements – a continuous process improvement for timely implementation
  • to be performed at the end of each iteration (usually once per month, or every week or two) with all development team members only for up to 1 hour
  • focus on what went well, what went wrong and how the team can improve in next iteration and beyond without finger-pointing
    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 chosen improvement stories will be put in the non-functional backlog to be carried out by the whole team to improve Agile processes
  • support the growth of the self-directed team for enhanced performance
  • 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, backlog item(s) may be identified for the next iteration
  • Retrospective Meeting vs Lessons Learned Meeting
    • Retrospective meeting is carried out once per iteration and identifies one area for improvement
    • Lessons Learned meeting is carried out 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)
• Task / Kanban Boards
  • Kanban literally means “visual signals”
  • Kanban Boards are boards placed in highly visible location with vital project information on project progress displayed, acting as an information radiator
  • adapted from the Lean Manufacturing Process and as a byproduct of just-in-time (JIT) process
  • the development states (e.g. Backlog, Analysis, Development, Test, Deploy, Done) would be identified as columns on the board with units of shippable products written on color-coded index cards to be put in various stages of the development
  • each index card would need to go from “Backlog” all the way to “Done” (called “flow”)
  • the emphasis is continuous development (i.e. flow)
  • Kanban is a pull-based system where team members “pull” the work from the backlog
  • WIP Limits
    • WIP means “Work In Progress” – a work that has been started but not yet reach “done”
    • WIP should be limited because
      • WIP represents investments but no value has been achieved yet
      • WIP represents risks in the form of potential rework as the work has not been accepted
      • WIP represents bottlenecks / inefficiencies in processes, etc.
    • WIP Limits are used in Kanban to limit the number of performing work in order to optimize the flow, once the WIP limit has been reached, no more new tasks are to be added to the ‘state’ and the team will work together to move current tasks forward
    • WIP = 5 means the team can only allow 5 tasks for a state (however the WIP limit should not be too low to actually realize the benefits)
    • aim to achieve efficiency through focusing on a limited number of tasks so that the team will work together as a whole to move the WIP onto completion
    • can be used to identify and clear bottlenecks and manage expectations
    • Little’s Law – the cycle time is proportional to the size of queue (WIP)
      • cycle time – the time required to wait for the benefits
      • more time is needed if the WIP is larger
  • Cumulative Flow Diagram (CFD)
    • used in Kanban to visualizes and identify trends and bottlenecks / waste of the project
    • plot the features (completed, WIP and total) against time
    • visualize the Little’s Law in the WIP portion
    • CFD can be plotted in more details by plotting the activities completed by individuals / teams
      • the slope indicates the rate of progress
      • a declining slope indicates bottleneck (below the widening band)
  • Theory of Constrains (TOC)
    • changes to most of the variables in an organization usually have only small impacts on global performance
    • need to find out the few variables that bring about significant changes
    • question 3 of daily stand up / daily Scrum addresses this theory by asking for any roadblocks that impediment progress
• Time-boxing
  • time-boxing is a concept for time management by treating time as fixed blocks
    • once the allotted time is up, the work must be stopped regardless of the progress
    • with fixed start time, fixed end time and fixed duration for the activity to control the risk and progress – the control in the chaos
    • focuses on the essentials and reduces wastes
    • especially suit to projects with high unknown factors
  • e.g. fixed iteration review demo sessions (usually once a week) in XP marks the end of the iteration, architectural spikes, daily stand-ups, etc.
• Release Planning
  • release planning is the meeting to plan the project schedule at a strategic level for delivering an increment of product value to the customers (can be date driven or feature driven)
  • consists of multiple iterations
  • make use of team velocity and story maps (group user stories into backbone, walking skeleton and additional elements) to plan the release
• Iteration Planning
  • is the meeting to plan and commit which user stories / backlog (usually with highest priority) to be turned into potentially shippable working software for the iteration based on the velocity of the team
  • iteration 0 is the work before the actual development work begins
    • technical and architectural setup
    • gathering initial requirements into the backlog, etc.
  • iteration H is the hardening iteration to test and prepare the software for launch
  • Steps of the Iteration Planning meeting
    1. Customer to pick product backlog items with highest priority (or the team to select backlog items from among the release backlog thru discussion with customer – the Product Owner has the final say in Scrum)
    2. Development Team to determine the tasks needed (as sprint backlog in Scrum)
    3. Team Members to choose the tasks through self-organization and estimate the time needed to compete the tasks (select the tasks themselves)
    4. Repeat until the capacities of all Team Members are full
  • Typical Agenda for Iteration Planning
    • Opening
    • Product Vision and Roadmap
    • Development status, state of architecture, results of previous iterations
    • Iteration name and theme
    • Velocity in previous iterations / estimated velocity
    • Iteration time-box (dates, working days)
    • Team capacity
    • Issues and concerns
    • Review and update definition of Done
    • Stories / items from the backlog to consider
    • Tasking out
    • New issues and concerns
    • Dependencies and assumptions
    • Commit
    • Communication and logistics plan
    • Parking Lot
    • Action Items / Plan
    • Retrospect the meeting
    • Closing
  • Iteration Planning vs Release Planning
    • Iteration planning involves schedule development at lower/detail level about tasks and time
    • Release planning involves schedule development at high level about features and iterations
• Burn down Chart
  • a graphical representation of “work remaining” vs “time remaining”
  • make project events (e.g. fluctuating team velocity, new stories added, etc.) visible for expectation management
  • a major way to report Agile metrics
  • a burn-down chart shows:
    • How much work has been done?
    • How much work remains?
    • The team’s velocity (the slope of the chart)
• Burn up Chart
  • a graphical representation of “work finished” vs “time remaining”
  • a line at the top indicating the project scope (the level can be changed when work is added / removed)
  • burn up vs burn down chart: burn down chart is simpler than burn up chart; yet if the project scope is evolving, burn up chart can offer a more realistic view of the progress of the project (scope changes/creeps are hidden in the burn down chart)
  • may may use of Cumulative Flow Diagram to also show the WIP in addition to the total scope and work done shown by burn up charts
• Process Tailoring
  • amend the Agile methodology to better fit the project environment since every project is different in terms of team size, nature, resources, criticality, etc.
    • e.g. at the end of each iterations, review meetings will be done to understand what can be improved by doing things differently. We can try to implement the changes in the next iteration to test.
  • Kanban is tailoring-friendly while Scrum is not
  • as a rule of thumb, it is recommended to implement the Agile methodologies out-of-the-box for the first few iterations before making changes / process tailoring so that the values of standard Agile methods are better understood before making changes.
    • relationship between different processes for Agile methodologies must be thoroughly understood before attempting to make changes
  • Shu-Ha-Ri model (by Alistar Cockburn) – originates from Japanese Noh theater
    1. Obeying the rules (Shu)
    2. Consciously moving away from the rules (Ha)
    3. Unconsciously finding an individual path (Ri)

Summary: Planning, Monitoring, And Adapting

This PMI-ACP® Exam Study notes touches upon one of the many tools and techniques of the PMI-ACP® exam syllabus – Planning, Monitoring, And Adapting. Planning, Monitoring, And Adapting knowledge includes retrospectives, task/Kanban boards, timeboxing, iteration and release planning, WIP limits, burn-down/up charts, cumulative flow diagrams and process tailoring.