PMI-ACP

Deck

AGILE VALUES

• Individuals and interactions over processes and tools

• Working software over comprehensive documentation (documentation should be barely sufficient)

• Customer collaboration over contract negotiation

• Responding to change over following a plan.

12 AGILE PRINCIPLES

1. Customer Satisfaction - our highest priority

2. Welcome Changes

3. Frequent Delivery

4. Collocated Team

5. Motivated Individuals

6. Face-to-face Conversation

7. Working Software

8. Constant Pace

9. Continuous Attention

10. Simplicity

11. Self-Organization

12. Regular Reflection

SCRUM

• Values: Commitment, Courage, Focus, Openness, Respect 

• 3 Pillars

  1. Transparency

  2. Inspection

  3. Adaptation

• Product Owner (PO) is responsible for maximizing the value of the product and the work of the team

  • 1 PO per team, but only 1 backlog for the whole product

  • Responsible/accountable for backlog management

  • The product owner represents the customer, users, and stakeholders. Take risk into account when prioritizing backlog

• Development Team

  • self-organizing, has all the skills needed, no titles, no sub-teams

  • "share 2 pizzas" = team size between 3 and 9 (not counting PO and Scrum Master). Other sources say the optimal team size is 8, others say 12.

• Scrum Master ensures the team understands and enacts Scrum

  • humility, servant leader

  • coaches the dev team and removes impediments

• ​Team practices Sashimi to ensure every slice of functionality delivered is complete

EXTREME PROGRAMMING (XP)

• Values: Simplicity, Communication, Feedback, Courage, Respect 

• 12 Practices

  1. Pair Programming - one person codes—the driver. The other person is the navigator, whose job is to think

  2. Planning Game

  3. Test Driven Development (TDD)

  4. Whole Team - everyone sits together, generalized specialists

  5. Continuous Integration

  6. Refactoring

  7. Small Releases

  8. Sustainable Pace

  9. Collective Code Ownership - multiple people work on all the code, any pair of developers can improve or amend any code.

  10. Coding Standard

  11. Simple Design

  12. System Metaphor

• Roles: Coach (= Scrum Master), Customer (= Product Owner), Developers, Testers

• Pair programming is the most helpful technique in implementing collective code ownership in a team

• Code goes through 4 levels of completion: Broken, Build, Ready for demo, Ready to release

LEAN

• Lean focuses on the Value Stream

• The 7 Lean principles:

  1. Eliminate waste

  2. Amplify learning (=early feedback loop)

  3. Decide Late (=defer as long as responsibly possible)

  4. Deliver Fast (=get value to the customer quickly)

  5. Empower the team

  6. Build integrity in (= test throughout, not just at the end)

  7. See the whole (=see the system not just the parts)

• Nonvalue-added time in Lean is the time in the cycle where we find delays, waste and constraints.

• Examples of Waste

  • Partially done work (e.g. untested code)

  • Extra processes (e.g. approval from manager who is not a true stakeholder)

  • Extra features (gold plating)

  • Task switching (e.g. if you're assigned to multiple projects)

  • Waiting (e.g. waiting on sign-offs)

  • Motion (e.g. poor communication between teams)

  • Defects 

KANBAN

• A key tool in lean manufacturing

• Focused sustainable pace and regular JIT delivery of individual items. Optimize the flow. 

• Core Practices

  • Define and visualize the workflow

  • Limit Work-In-Progress (WIP) 

  • Measure and Manage Flow

  • Make Process Policies Explicit

  • Use Models to Suggest Improvement

• In practice, start by 1) visualizing the flow of work to identify bottlenecks, 2) speed up or remove the bottlenecks that affect overall throughput 3) establish WIP limits, and then 4) look for continuous improvement. 

• Compared to Agile, Kanban focuses on continuous flow (vs. fixed iterations) and cycle time (vs. velocity)

• Cycle time = # completed items/# days, the average time between the delivery of completed work items. For example 10 completed items in 5 days means a cycle time of 0.5 days/item.

• Task Board serves the dual purpose of giving the team a convenient mechanism for organizing their work and a way of seeing at a glance how much work is left. Can be a whiteboard, cork board, cardboard, etc.

  • Lets you visualize the workflow and identify constraints. 

  • ​On a task board you have 3 basic columns: to-do, in-progress, done. 

  • The WIP number on the board is the max number of work items in a swim lane.

  • Kanban board uses a pull system

• Little's Law: # of items in the system = Rate items enter the system x Average time items spend in the system. Demonstrates that the duration of work queue is dependent on its size. Following Little's Law, to improve cycle time, reduce WIP (work in progress) and increase ACR (average completion rate). 

• Throughput is the number of features the team can develop in a particular amount of time.

• A testing team finds that it is often in the firing line as they often have more work than they can handle. In the Kanban system the best way to handle this is to limit the WIP. This will address the feeling of being overwhelmed with work and pave the way for more creative solutions to the problem.

• David Anderson 5'S for Kanban agile development: Set in order, Sort, Shine, Standardize, Sustain 

• Scrumban is a hybrid of Scrum and Kanban

AGILE CHARTER AND PROGRAM

• Agile charters answer the W5H questions (who? what? where? when? how?)

  • Charter doesn't specify costs or specific team members

  • If the charter doesn't exist, create one with the sponsor

• 5 Phases of Agile Project Management: Envision, Speculate (including release plan and stories), Explore, Adapt, Close

• Planning Onion: Strategy, Portfolio, Product, Release, Iteration, Day. Team is mainly involved starting at Release.

• 4 types of revenue

  • ​New revenue (from new markets, customers, features)

  • Incremental revenue (existing features are enhanced, add-on's, encourage customer to buy more)

  • Retained revenue (what you will lose if you don't develop key features, could relate to regulatory)

  • ​Operational Efficiences (internal improvement)

PLANNING TECHNIQUES

• In agile you will spend more time planning overall than in waterfall! However the planning is spread out over the course of the project.

• Vision and requirements gathering:

  • Design the Box - break into small groups and design the product name, graphic, elevator pitch on the front, detailed features on the back, and operating instructions

  • Prune the Tree - a requirements gathering technique

  • ​Remember the Future

PLANNING TECHNIQUES 2

• Prioritization: 

  • MoSCoW

    • Must Have – Critical to the current delivery timebox in order for it to be a success

    • Should Have – important but not necessary for delivery

    • Could Have – Desirable, but not necessary; Could improve user experience or customer satisfaction for very little cost

    • Won’t Have – Have been agreed by stakeholders as the least-critical and not to be delivered in the current timebox

    • MustHave+ShouldHave = business case. Must+Should+Could = business case + contingency, 100% of total.

  • Kano Analysis: 

    • Exciters/Delighters – features deliver unexpected benefits to the customer

    • Performance/Satisfiers/Threshold/Must-Have – features deliver expected benefits to the customer

    • Basic/Dissatisfiers – If these features are missing, customers will be unhappy

    • Indifferent – Customers do not care if these features are in the product or not

      • Performance – Linear relationship between functionality/quality and customer satisfaction

      • Excitement – Customers will be willing to pay premium for these features, lack of features will not decrease satisfaction

      • Basic – Making these better, will not improve customer satisfaction, best is neutral • Indifferent – Minimize these features inclusion

      • Basic/Dissatisfiers are most important compared to Delighters or Satisfiers. This will cause the customer to dislike a product if they are not present. Indifferent features should be minimized or eliminated. 

  • Relative Weighting - priority of a feature is determined by dividing the priority % by the cost %

  • Bang for the Buck, Buy a Feature, 100 Point Method

PLANNING TECHNIQUES 3

• Estimation

  • Affinity estimating (e.g. T-Shirt sizing) is the practice of using common sizes to rapidly place user stories into similarly sized groups - good for when you have at least 20 stories, ideally 40 stories or even 100s of stories. Each story is placed on a table and one by one a team member is given an opportunity to place a card in line or adjusting a card in the line already.

  • Wideband Delphi (e.g. Planning Poker) estimation includes plotting estimates on a chart with no names, and then the range of points is discussed, and the team attempts to reach a general consensus. Wideband Delphi is anonymous estimates which minimizes the Bandwagon effect, HIPPO decision making and Groupthink

• Decision making: Fist to five, thumbs up, thumbs down or thumbs sideways, and decision spectrum, Dot Voting (stickies), Forced Ranking (score criteria, then rank in order based on score)

• Buy a story is a collaboration game to help stakeholders understand a complex issue

• Brainstorming: Round robin, Quiet Writing, Free for all. 

• Collaboration: Listening Game, Collaborative Origami, 123 Go

BACKLOG, EPICS, USER STORIES

• User stories are not the same as "use cases" or "design scenarios". They are support tools for analysis.

• User stories should be written following INVEST principles:

  • ​I: Independent

  • N: Negotiable

  • V: Valuable

  • E: Estimable

  • S: Specific (or Small)

  • T: Timely (or Testable)

• Each story has 3 elements, the 3 C's

  • the Card (the story should fit on a 3" x 5" card)

  • the Conversation (user stories are communicated by end-users to developers)

  • the Confirmation (the acceptance criteria)​

• A story map is like a product roadmap, using future stories to be implemented. Story mapping is used to identify missing stories, categorize stories into functionality and prioritize stories.

• Epic stories are large stories that have not been broken down, and these are typically found at or near the bottom of the product backlog.

• Disaggregation refers to splitting a story or feature into smaller, easier-to-estimate pieces (NOT decomposition)

• Small stories such as cosmetic UI changes and reading/writing bug reports can be combined into larger stories

• Spikes: architectural spike (e.g. proof of concept), risk-based spike

• Research stories should last 1 day

• Acceptance criteria come from the customer, even if ultimately a team member might be the one to write them down

• Theme is a set of related user stories that may be combined together and treated as a single entity for either estimating or release planning.

• Quantity of function is scope measured in terms of user stories, use cases, requirements, or features

• The risk-adjusted backlog is a primary way in which risk is managed. Stories in a risk-adjusted backlog are prioritized based on EMV (expected monetary value).

• Grooming the backlog = refinement = adding detail, add/remove stories, prioritize

RELEASE PLANNING, ITERATION PLANNING and STAND-UPS

• When release planning:

  • slice stores

  • estimate velocity

  • select stories

• Waves/milestones are intermediate 1-3 month timeframes with story-level capability and commitment. When a milestone is achieved, someone can verbally announce it ("declaration milestone")

• Definition of ready determines when an item is ready for development (ie. when it can go into an iteration)

• Staging is the process of defining and prioritizing the nonfunctional requirements. Occurs prior to the start of the first Sprint and takes just one day. 

• Iteration planning includes the defining of tasks on an agile project. Break stories into tasks during iteration planning

• Tasks are self-assigned by the team. If no one wants a task, the team collectively decides. Task assignments are done by the team in a self-organized agile team

• Tasks are estimated at the time of Iteration Planning as well as during the iteration

• The PO shouldn't attend the standup which is a meeting of, for, and by the team

• End of iteration demo is called a product review meeting

AGILE PROJECT SCHEDULE

• The agile project schedule is created by estimating story points and applying velocity.

• Sprint 0 (or 'Iteration 0') does not deliver customer value. It can include initial training.

• Actual time is the amount of time an assignment would take to complete. Ideal time is the amount of time an assignment would take if there were no interruptions or distractions. The conversion to elapsed time depends upon individuals involved but can usually be reasonably estimated at an aggregate or team level.

• If project is release-timeboxed, a team can maintain a feature buffer and follow a MoSCoW scheme to logically sequence the work.

• To avoid bottlenecks, it is recommended to get the team to be generalists so anyone can pick up any task.

• Biggest advantage to delivering incrementally is that it reduces the amount of rework by finding issues earlier. 

• Velocity = number of story points a team can complete in a single iteration

• A team's velocity is not likely to be comparable to another one, so using industry standards or using velocity to compare to teams is meaningless. Calculate velocity in the early sprints by team consensus or using team capacity. Compare teams by ROI, not by velocity.

• The team should get to predictable velocity

• Lead time is the amount of time needed to get a feature from inception to live deployment (not velocity)

• Feeding buffer is applied to stories that depend on other stories, in case the dependencies are late

RETROSPECTIVES

• Format of meeting (15-60min):

  1. Set the stage

  2. Problem solving: gather data, generate insights, decide what to do 

  3. Closing

• Set the stage

  • Everyone sits in circle or semi-circle

  • Techniques: Check In, Focus On/Off, ESVP and Working Agreements.

    • ESVP is a technique used to anonymously identify team members' attitudes towards retrospectives as: Explorers, Shoppers, Vacationers, Prisoners.

• Generate insight techniques: Brainstorming,  Pair Interviews

• Force field analysis = analyzing factors that drive change and restrict change

• Decide what to do techniques: Short Subjects, Triple Nickels, Voting with Dots

• Closing ​techniques: Plus/Delta or Speedboat to ask what team want more/less in next iteration regarding process. 

• ARCS, criteria for evaluating Instructional designs: 

  • Choose activities that help people stay engaged so they don’t drift off (Attention)

  • That are relevant to the goal (Relevance).

  • You want activities that people can accomplish successfully (Confident/Competence).

  • Finally, make sure activities fit into the overall design so people think the retrospective is a good use of their time (Satisfaction).

• Return on Invested Time (ROTI) is used to determine the quality of the retrospective.

• You have Release Retrospectives, Project Retrospectives, Iteration Retrospectives and Surprise Retrospectives. Surprise Retrospective is conducted when an unexpected event changes your situation.

AGILE MODELING

• Agile modelling techniques are:

  • use cases

  • data diagram

  • screen designs

DEVOPS

• DevOps helps speed up the deployment of products from development to operations

• Continuous integration (CI) is executed when code changes are checked in and tested daily. CI components include source code control system, build tools, test tools, scheduler/trigger, notifications BUT NOT UNIT TESTS

AGILE CONTRACTS

• If schedule variance is expected, use graduated fixed price contracts (when both parties share some of the risk and reward associated with schedule variance)

• A DSDM Contract focuses on work being "fit for business purpose"

• "Money for nothing" in Agile contracting created by Jeff Sutherland means customer can terminate early

INFORMATION RADIATORS, KPIs

• Information radiators include: burn charts, retrospective learnings, story maps (but not the definition of done)

• Some stakeholders may want a vision statement. Next most detailed is the roadmap. Then the detailed release plans and iteration plans.

• The burnup chart plots time on the X-axis and functionality on the Y-axis.

  • Get a bird’s-eye view of the project.

  • Shows progress and predicts a completion date.

  • Burnup charts can show the impact of scope changes. Usually product when you update the release plan.

• The burndown charts are used to track scope and schedule progress of the project. A cumulative story point burndown chart is useful because it shows the total number of story points completed through the end of each iteration.

  • Example in practice: start at 200 points, the team completes 50, the PO adds 20 more. As 20 points get added, the bottom of the bar shifts down by 20 points and reads "-20". The top of the bar moves down as the team completes the work. As 50 points are completed, the top will be at 150.

• 4 KPIs used in Agile are

  • remaining work

  • rate of progress

  • likely completion date

  • likely costs remaining

• Best metric to compare agile teams: ROI, not velocity

• A S-curve is a graph that tracks a variable over time. 

• EMV chart is a leading indicator which is why it is better than a GANTT chart.

• Trend analysis is a lead metric as it helps forecast issues based on trends.

QUALITY

• An escaped defect is a defect that wasn’t discovered by test teams. Instead, the defect was found by customers.

• Component tests (as opposed to unit tests) verify that units and combinations of units work together

• Error-feedback ratio is the number of new defects injected when fixing existing defects (e.g., 20 new defects generated in fixing 100 defects would be an error-feedback ratio of 20%)

• Capers Jones concluded "a cumulative defect removal rate of 95% on a project appears to be a nodal point where several other benefits accrue"

PMP FINANCIAL FUNDAMENTALS, APPLIED TO AGILE

• Net Present Value (NPV) • The present value of the cash flows, at the required rate of return of your project, compared to your initial investment

  • To compare projects, use NPV. The higher NPV the better.

  • Time value of money

  • A positive NPV means the project is profitable, a Negative NPV means the project is not profitable

  • Drawbacks – Need to make assumptions are inflation and interest rates

• Internal Rate of Return (IRR) • The discount rate that makes the NPV of all cash flows equal to zero • Removes the assumptions of interest and inflation rates • Complicated to calculate, expressed as a %. When comparing projects, chose the project with the higher IRR.

  • Note that IRR is a superior measure to NPV, and should be used for making decisions in benefit-cost analysis.

• ROI = Benefits/Investment. Higher is better. Example • Feature costs – $100,000, Net Profit (i.e. benefits)- $25,000, therefore ROI = 25% • Drawback – Revenue generated after the period of time, time value of money.

• The payback period is a calculation where a shorter payback period is preferred over a larger period.

OTHER PMP FUNDAMENTALS

• Earned value management (EVM) in an agile project should be measured at the iteration level, because this is the level where velocity is measured and resources are applied.

• Kaizen is the term for making small changes. The Plan-Do-Check-Act (PDCA) is the cycle developed by Edward Deming for implementing small improvements.

• Common causes vs. special causes. Too often common causes are mistaken for special causes. If it's a common cause, do nothing.

LEARNING

• When a team is trying to learn agile, First they need to "think", meaning individually learning and internalizing agile principles (think first, then do).

• In Agile, you can change the plan when something new is learned or when it is known that a mistake is to be avoided. You don't have to wait for the end of the iteration.

• The 3 Agile coaching styles are Training/Teaching, Coaching and Mentoring/Advising (not supporting). When the team is storming, you should coach with a focus on conflict resolution.

• Listening types: 1. internal 2. focused 3. global

• Shu Ha Ri. Shu: Follow the rule. Ha: Break the rule. Ri: Be the rule.

• For looking at how a team can improve, there are 3 levels

  • The process level: How are we doing with agile?

  • The quality and performance angle: How can the team produce better?

  • The team dynamics dimension: How can the team become a better team?

• Lyssa Adkins guidelines for one-on-one coaching are guarantee safety, meet them a half-step ahead, partner with managers and create positive regard

TEAM BUILDING AND COMMUNICATION

• Servant leadership: shield the team, remove impediments, carry food and water

• Caves and common area are essential for a team space so the team have caves where they can work in quiet and a common area where knowledge sharing can happen

• Decision framing focuses on who gets involved in the decision process. Who makes the decision is less important than getting the right people involved in the decision process.

• Health checks, often questionnaires, help determine how well the team is adhering to Agile process.

• When facilitating meetings the facilitator is responsible for the goals, rules, timing, assisting, including meeting minutes

• During problem solving, ask questions and listen, but avoid injecting your own ideas

• After understanding ones own feelings next is to manage them and then become more aware of others and finally they will be able to influence others feelings.

• The 5 dysfunctions of a team are Absence of Trust, Fear of Conflict, Inattention to Results, Avoidance of Accountability, Lack of Commitment

• Level-based conflict. It's best to empower the team members to solve conflict themselves (e.g. Level 2 conflicts), unless the temperature is really high

• For announcing sprint priorities, two-way communication model ensures information is bidirectional. 

MISC

• FDD methodology is all about modelling

• Crystal methodology has more ceremony based on the size of the team and the criticality of the project.

• Normative methodologies are based on solutions or sequences of steps known to work for the discipline

• Workshops are meetings where work gets accomplished (different from status meeting or knowledge transfer).

• Learn Cockburn's failure modes and 7 anti-patterns for a methodology

• Blanchard and Hersey's situational leadership stages in sequence are: Directing, Coaching, Supporting, Delegating

• Be aware of the Dreyfus model of adult skill acquisition: Novice, Advanced Beginner, Competent, Proficient and Expert

• Be aware of Tuchman team formation and development and Shu-Ha-Ri of skill mastery ​

• SMART goals are Specific, Measurable, Attainable, Relevant, Timely​​