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

 Customer Satisfaction - our highest priority

 Welcome Changes

 Frequent Delivery

 Collocated Team

 Motivated Individuals

 Face-to-face Conversation

 Working Software

 Constant Pace

 Continuous Attention

 Simplicity

 Self-Organization

 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. 1 PO per team, but only 1 backlog for the whole product

2. Responsible/accountable for backlog management

 3. The product owner represents the customer, users, and

stakeholders. Take risk into account when prioritizing backlog

 Development Team

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

2. "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

1. humility, servant leader

2. 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

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

2. Extra processes (e.g. approval from manager who is not a true

stakeholder)

3. Extra features (gold plating)

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

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

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

7. 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

 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

 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):

 Set the stage

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

 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