Agile Principles and Mindset

DOMAIN I
What is Agile?

 Developed for Software projects, but it is a methodology that can be used on all Project types.
 Agile is an umbrella term that is used to refer to different types of iterative development.
 Scrum is the most common method of agile, there are others such as extreme programming (XP), lean
development, and Kanban.

Agile vs. Traditional Project Management

 Agile builds in increments vs. as a whole
 Agile does planning throughout vs. done all at once.
 Agile delivers products over time vs. all at once
 Customers see value faster vs. at the end.
 Agile wants changes vs. discouraging changes

Agile Benefits
 Customer involved throughout the life cycle.
 Greater Customer Interaction with all stakeholders
 Constant Feedback is required to stay current and successful.
 Greater Value up front
 Change is welcomed by all stakeholders.

Agile Concurrent Development

 Fund incrementally – opt to extend, redirector cancel at a very granular level.

 Deliver & realize value steadily.
 Validate designs with users & customers.
 Continuously adapt to risk and change
 Integrate early & often.

Agile Declaration of Interdependence (DOI)

 Agile and adaptive approaches for linking people, projects, and value.
 We are a community of project leaders that are highly successful at delivering. results. To achieve these
results:
 We increase return on investment by making continuous flow of value our focus.
 We deliver reliable results by engaging customers in frequent interactions and shared ownership.
 We expect uncertainty and manage it through iterations, anticipation, and adaptation.
 We unleash creativity and innovation by recognizing that individuals are the ultimate source of value,
and creating an environment where they can make a difference.
 We boost performance through group accountability for results and shared responsibility for team
effectiveness.
 We improve effectiveness and reliability through situationally specific strategies, processes, and
practices.
 Agile Mindset
 Welcoming change
 Working in small value increments
 Using build and feedback loops
 Learning through discovery
 Value -driven development
 Failing fast with learning
 Continuous delivery
 Continuous improvement
Inverting the Triangle

Agile Manifesto
Create in 2001
Contains:
 4 values
 12 guiding principles
https://agilemanifesto.org/

The Agile Manifesto Values

We are uncovering better ways of developing software by doing it and helping others do it.
Through this work we have come to value:

That is, while there is value in the items on the right,

we value the items on the left more.
www.agilemanifesto.org

Individuals and interactions over processes and tools

 While processes and tools will likely be necessary on our projects, we should focus the team's attention
on the individuals and interactions involved.
 Projects are undertaken by people, not tools.
 Problems get solved by people, not processes.
 Projects are ultimately about people.
 Working software over comprehensive documentation
 Focus on the delivery value vs. paperwork.
 Agile documents should be barely sufficient.
 Done just in time.
 Done just because.
 Delivering software that does what it should come first, before creating documentation.
 Agile dramatically simplifies the administrative paperwork relating to time, cost, and scope control.

Customer collaboration over contract negotiation

 Be flexible and accommodating, instead of fixed and uncooperative.
 Manage change, don’t suppress change.
 Shared definition of “done”.
 Requires trusting relationship.

Responding to change over following a plan

 Spend effort and energy responding to changes.
 Software projects tend to have high rates of change.

12 Agile Guiding Principles

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile processes harness change for the
customer's competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the
shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they need and trust
them to get the job done.
6. The most efficient and effective method of conveying information to and within a development team is face-
to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers) and users should be able to
maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity; the art of maximizing the amount of work not done is essential.
11. The best architecture, requirements and designs emerge from self-organizing teams.
12. At regular intervals, the team reflects on how to become more effective then tunes and adjusts its behavior
accordingly.

Agile Methods
 Over 12 agile methodologies
 Scrum
 Extreme Programming (XP)
 Kanban Development
 Lean Software Development
 Agile Terms
Product Owner - Designated person that represents the customer on the project.
Agile Project Manager/Scrum Master – Manages the agile project.
Product Backlog - Project requirements from the stakeholders
Sprint Planning Meeting- Meeting done by the agile team to determine what features will be done in the next
sprint.
Sprint Backlog – Work the team selects to get done in the next sprint.
Sprint - A short iteration where the project teams work to complete the work in the sprint backlog, (1-4 weeks
typical)
Daily Stand-Up Meeting - A quick meeting each day to discuss project statuses, led by the Scrum Master.
Usually, 15 minutes
Sprint Review – An inspection done at the end of the sprint by the customers.
Retrospective – Meeting done to determine what went wrong during the sprint and what when right. Lesson
learned for the sprint.
Partial Completed Product - Customers Demo the product and provide feedback. This feedback adjusts the next
Sprint priorities.
Release - Several Sprints worth of work directed to operations for possible rollout and testing.

Sprint = Iteration

Agile Process

Scrum

Set of team guidance practices, roles, events, artifacts, and rules

Based on three pillars of Transparency, Inspection, and Adaptation:

Transparency
Visibility to those responsible for the outcome
Inspection
 Timely checks on how well a project is progressing toward goals.
 Looks for problematic deviations or differences from goals.
Adaptation
Adjusting a process to minimize further issues if an inspection shows a problem or undesirable trend
 Scrum Roles & Responsibilities
Product Owner
 Owns Product vision.
 Defines features, decides on release date and content.
 Responsible for market success
 Prioritizes features according to market value.
 Can change features and priorities every Sprint.
Scrum Master
 Responsible for facilitating process.
 Focuses Team and protects them from external Interruption.
 Looks for ways to enhance productivity.
 Assists Product Owner in leveraging Scrum.
Development Team
 Small group containing all necessary project skills.
 Focuses on steady delivery of high-quality features.
 Generates options for delivery.
 Manages own work within Sprints.
Scrum Activities

The Scrum methodology refers to several different types of activities:

1. sprint planning meeting

2. sprints
 Daily stand-up meeting
3. sprint review meeting
4. sprint retrospectives.

Sprint Planning Meeting

 Used to determine what work will be done in that sprint and how the work will be achieved.
 The development team predicts what can be delivered based on estimates, projected capacity, and past
performance to define the sprint goal.
 The development team then determines how this functionality will be built and how the team will
organize to deliver the sprint goal.
 Output of this will be the sprint backlog. The work to get done in the next sprint.

Sprints
 A sprint is a timeboxed (time-limited) iteration of
 1-4 weeks to build a potentially releasable product.
 Each sprint includes a sprint planning meeting,
 daily Scrum, the actual work, a sprint review
 meeting, and the sprint retrospective
 During the sprint, no changes are made that.
 would affect the sprint.
 The development team members are kept the
 same throughout the sprint

Daily Scrum (or Standup)

 A 15-minute time-boxed activity for the Development Team to synchronize activities and create a plan
for the next 24 hours.
  Should be held at the same time and place each day
 Each team member should answer 3
questions:
1. What did you do yesterday?
2. What will you do today?
3. Are there any impediments in your way?

Sprint Review
 Takes place at the end of the Sprint
 Designed to gather feedback from stakeholders on what the Team has completed in the sprint
 Team demonstrates work that was completed during the sprint
 To create a conversation between the Team and the stakeholders about how to make the product
better.
 should be time boxed to no more than an hour per week of Sprint.

Sprint Retrospective
 Opportunity for the Team to inspect and create a plan for improvements to be done during the next
Sprint.
 Team discusses:
 What went well.
 What went wrong.
 What to do more of
 What to do less of
Scrum Artifacts
 Product increment
 Part of the product that is complete after each sprint.
 Product Backlog
 Prioritized list of valuable items to deliver.
 Sprint Backlog
 List of committed items to be addressed within Sprint.

Product Backlog
 Prioritized list of all work that needs to be done to complete the product
 List is dynamics, it evolves as the more work is added and prioritized
 Items in it is prioritized by the product owner and is sorted by value
 Most valuable items are listed first.
 Constantly being refined as more work is added to it.
 Team and product owner will “groom the backlog”.

Product Increment
 Part of the product that is done after each sprint.
 Done to get feedback after each sprint.
 The product owner and team need to agree upon the “definition of done” before the team starts
working on the product.
Sprint Backlog
 The sprint backlog is the set of items from the product backlog that were selected for a specific sprint.
 The sprint backlog is accompanied by a plan of how to achieve the sprint goal, so it serves as the
development team's forecast for the functionality that will be part of the sprint.
  It is a highly visible view of the work being undertaken and may only be updated by the development
team.
Definition of Done (DoD)
Definition of Done (DoD) is a shared understanding of what it means when work is considered done, it should
be defined at the beginning of the project, and it applies globally to the project. Definition of Done (DoD) is a
crucial element. of a successful scrum software development Might include things such as:
 DoD for Unit & functional tests.
 DoD Documentation.
 DoD for a Writing code.
Extreme Programming (XP)

 Software development centric agile method

 Focus software development good practices
 Scrum at the project management level focuses on prioritizing work and getting feedback.

XP Core Values
Simplicity

 Reduce complexity, extra features, and waste.

 “Find the simplest thing that could possibly work"

Communication

 Team members know what is expected of them and what other people are working on
 Daily stand-up meeting is key communication component.

Feedback

 Get impressions of correctness early

 Failing fast allows for faster improvement.

Courage

 Allow our work to be entirely visible to others.

Respect

 People work together as a team, and everyone is accountable for the success or failure of the project
 Recognize people work differently and respect those Differences.

XP Roles
Coach:
 Acts as a mentor, guiding the process and helping the team stays on track. Is a facilitator helping the
team become effective.
Customer:
 Business representative who provides the requirements, priorities, and drives the business direction for
the project.
Programmers:
 Developers who build the product. Writes the codes.
Testers:
 Helps the customer define and write the acceptance tests. for the user stories.
Product Owner and Customer are equivalent.
ScrumMaster and Coach are equivalent.

XP Practices
Planning Activities (Games):

 Release Planning:
 Push of new functionality all the way to the production user
 Customer outlines the functionality required.
 Developers estimate difficult build.
 Iteration Planning:
 Short development cycles within a release (Scrum calls "sprints”)
 Conducted at the start of every iteration, or every two weeks.
 Customer explains functionality they would like in iteration.
 Developers break functionality into tasks and estimate work.
 Based on estimates and amount of work accomplished in previous iteration,
 Small Releases:
 Frequent, small releases to test environments
 Demonstrate progress and increase visibility for the customer.
 Quality is maintained: Rigorous testing or Continuous integration Customer Tests:
 Customer describes one or more tests to show software is working.
 Team builds automated tests to prove software is working. Collective Code Ownership:
 Any pair of developers can improve or amend any code.
 Multiple people work on all code, which results in increased visibility and knowledge of code base
 Leads to a higher level of quality; with more people looking at the code, there is a greater chance
defects will be discovered.
 Less risk if programmer leaves, since knowledge is shared.
 Code Standards:
 Follow consistent coding standard.
 Code looks as if it has been written by a single, knowledgeable programmer Sustainable Pace:
 While periods of overtime might be necessary, repeated long hours of work are unsustainable and
counterproductive.
 The practice of maintaining a sustainable pace of development optimizes the delivery of long-term
value.
 Metaphor:
 XP uses metaphors and similes to explain designs and create a shared technical vision.
 These descriptions establish comparisons that all the stakeholders can understand to help explain how
the system should work.
 For example, “The invoicing module is like an Accounts receivable personnel who makes sure money
collected from our customers”.
 Continuous Integration:
 Integration involves bringing the code together and making sure it all compiles and works together.
 This practice is critical, because it brings problems to the surface before more code is built on top of
faulty or incompatible designs.
 Test -Driven Development (TDD):
 The team writes tests prior to developing the new code.
  If the tests are working correctly, the initial code that is entered will fail the tests
 The code will pass the test once it is written correctly.
 Pair Programming:
 In XP, production code is written by two developers working as a pair to write and provide real-time
reviews of the software as it emerges.
 Working in pairs also helps spread knowledge about the system through the team.
 Simple Design:
 Code is always testable, browsable, understandable, and explainable.
 Do the simplest thing that could possibly work next. Complex design is replaced with simpler design.
 The best architecture, requirements, and designs emerge from self-organizing teams.
 Refactoring:
 Remove redundancy, eliminate unused functionality, and rejuvenate obsolete designs.
 Refactoring throughout the entire project life cycle saves time and increases quality.
 Code is kept clean and concise, so it is easier to understand, modify, and extend.

Some Basic Terminology Review

Lean Software Development

Lean was started by Toyota as a manufacturing method that was applied to software development.

Principles:
 Using visual management tools
 Identifying customer-defined value
 Building in learning and continuous improvement

Lean Software Development

 Lean Software Development
Eliminate waste:
 To maximize value, we must minimize waste. For software systems, waste can take the form of partially
done work, delays, handoffs, unnecessary features.
Empower the team:
 Rather than taking a micro-management approach, we should respect team member’s superior
knowledge of the technical steps required on the project and let them
Deliver fast:
 Quickly delivering valuable software and iterating through designs.
Optimize the whole:
 We aim to see the system as more than the sum of its parts.

Lean Software Development

Build quality in:
 Build quality into the product and continually assure quality throughout the development process
Defer decisions:
 Balance early planning with making decisions and committing to things as late as possible.
Amplify learning:
 This concept involves facilitating communication early and often, getting feedback as soon as possible, and
building on what we learn.
Seven Wastes of Lean
1. Partially done work
2. Extra Processes
3. Extra features
4. Task switching
5. Waiting
6. Motion
7. Defects
Kanban Development
Kanban development is derived from the lean production system used at Toyota. “Kanban" is a Japanese word
meaning "signboard."
 Kanban five core principles:
Visualize the workflow:
 Software projects, by definition, manipulate knowledge, which is intangible and invisible.
Limit WIP:
 Keeping the amount of work in progress low increases the visibility of issues and bottlenecks.
Manage flow:
 By tracking the flow of work through a system, issues can be identified, and changes can be measured for
effectiveness.
Make process policies explicit:
 It is important to clearly explain how things work so the team can have open discussions about improvements.
Improve collaboration:
 Through scientific measurement and experimentation, the team should collectively own and improve the
processes it uses.
Kanban Limit Work in Progress

https://herdingcats.typepad.com/my_weblog/2014/08/theuse-and-misuse-of-littles-law.html

Other agile methods

Feature-Driven Development
 The team will first develop an overall model for the product then build a list, and plan the work.
Dynamic Systems Development
 One of the first agile methods and follows eight principles.
Crystal
 It’s a customized methodologies that are coded by color names.
 Leading Effectively
Tap into people’s intrinsic motivations.
 Discover why team members want to do something and what motivates them to do and then align
that to the project goals.
Management vs Leadership
 Management > Mechanical Focus
 Leadership > Humanistic Focus (on people and purpose)

Leading Effectively
Servant Leadership
 Leader provides what the team needs.
1. Shield team from interruptions
2. Remove impediments to progress
3. (Re)Communicate project vision
4. Carry food and water
Twelve Principles for Leading Agile Projects
1. Learn the team members needs
2. Learn the project requirements
3. Act for the simultaneous welfare of the team and the project
4. Create an environment of functional accountability
5. Have a vision of the completed project
6. Use the project vision to drive your own behavior
7. Serve as the central figure in successful project team development
8. Recognize team conflict as a positive step
9. Manage with an eye toward ethics
10. Remember that ethics is not an afterthought, but an integral part of our thinking
11. Take time to reflect on the project
12. Develop the trick of thinking backwards

Leadership Tools and Techniques

Using these tools still needs a soft skills approach.

Modeling Desired Behavior
 Honesty
 Forward-Looking
 Competent
 Inspiring
Communicating project vision
Enabling others to act
 Switch from exclusive tools to inclusive tools
 Being willing to change the status quo.
 Leadership Task
 Practice Transparency through Visualization.
 Create a safe environment for experimentation.
 Experiment with new techniques and processes.
 Share knowledge through collaboration.
 Encourage emergent leadership vis a safe Environment.

Value-Driven Delivery
Value-Driven Delivery

Projects undertaken to generate business value.

 Produce Benefit
 Improve Service
 Market Demand
 Safety Compliance
 Regulatory Compliance
Early Value Delivery
Agile promotes early and often delivery.

Aim to deliver highest value early in project.

 Deliver as many high-value components as soon as possible.

o Reduces risk.
 Stakeholder satisfaction >Project success
o Shows understanding of stakeholders’ needs.
o Stakeholders are engaged.
o Builds confidence of stakeholders in team
Reduce Waste
Minimize Waste, e.g:

 Partially done work.

 Extra processes
 Extra features
 Waiting
 Defects
Assessing Value - Financial Metrics
Return on investment (ROI)
 The ratio of the benefits received from an investment to the money invested. Usually, a percentage

Internal rate of return (IRR).

 Interest rate you will need to get in today. money to receive a certain amount of money in the future.
Present Value/Net Present value (NPV)
 Value of future money in today’s terms

Assessing Value - Financial Metrics

Earned Value Management

  Formulas that monitor the value of the project as it is progressing.

Accounting on Agile Projects

 Refers to how the different economic models of agile work.

 Agile accounting is different than traditional accounting.
 Agile looks to deliver value as quickly as possible.
 Uses minimal viable product (MVP)
 This leads to more opportunity for incremental funding.

Key Performance Indicators (KPI’s)

Uses as a way to measure the project progress.

o Rate of progress: How many points have been completed.
o Remaining work: How much work is yet to be done from the backlog.
o Likely completion date
o Likely Cost remaining.
Regulatory Compliance

 Mandated requirements usually by government agencies

 Must be implemented into the project work as regular development work.
 Doing it after the project work is done.
Risk Management
 Risk is closely related to value.
 Considered as anti-value.
 Usually has the potential to remove, erode or reduce value with threats.
Managing Risks Process

Tools to Manage Risk

 Risk-adjusted backlog
 Risk burndown chart
 How Customers Conduct Value Prioritization

 Valued based prioritization is one of the core practices in agile planning.

 Features are prioritized on the basis of business value, risk and dependencies.
Some of prioritization techniques used:

o Simple Scheme
o MoSCoW prioritization
o Monopoly Money
o 100-point method
o Dot Voting or Multi-voting
o Kano Analysis
o Requirements Prioritization Model
o
Prioritization Techniques
Simple Scheme:
o Priority 1, Priority 2, Priority 3, etc.
o Could be problematic as many items might become the first priority.
MoSCoW prioritization:
o Must have
o Should have.
o Could have
o Would like to have, but not this time.

Prioritization Techniques
Dot Voting or Multi-voting
o Each person gets a certain number of dots to distribute to the requirements.
Monopoly Money
o Give everyone equal monopoly money.
o They then distribute the funds to what they value the most.
100-point method
o Each person is given 100 points.
o They then use that to distribute to individual requirements.

Prioritization Techniques
Kano Analysis
o Helps to understand the customers’ satisfaction.
o Delighters/Exciters
o Satisfiers
 o Dissatisfiers
o Indifferent

https://foldingburritos.com/kano-model/

Prioritization / Ranking is Relative

Doesn’t matter what techniques the customer uses priority; the end results should be a list of prioritized
features.
Delivering Value Incrementally
Incremental delivery is about deploying.
working parts of a product over the life of the project
In software development, it’s first delivered to a testing environment then to production.
This will reduce the amount of rework by discovering issues early and fixing them.

Delivering Value Incrementally

http://www.agilemodeling.com/essays/costOfChange.htm

Minimal Viable Product (MVP)

 Refers to a set of functionalities that is complete to be useful, but small enough not to be an entire
project.
 Usually, a module in a software.
 Tools for Agile Projects

Low-tech, high touch over computer models

When using computer models problems could arise such as:

o Data accuracy perception increases.

o No stakeholder interaction. Only a few people
o would update them.
Low-Tech, High-Touch Tools

 Use cards, charts, whiteboards, and walls.

 Promotes communication and collaboration.
 Skip using a computer Gantt chart to a
 Kanban board
Kanban/Task Board

 An "information radiator" - ensures efficient diffusion of information.

 Can be drawn on a whiteboard or even a section of wall.
 Makes iteration backlog visible.
 Serves as a focal point for the daily meeting.

Limit WIP (Work in Progress)

 Includes work that has been started but not completed yet.
 Represents money spent with no return.
 Hides process bottlenecks that slow the processes.
 Represents risk in form of potential risk.
 Agile processes aim to Limit and optimize WIP.
 Optimal WIP makes processes efficient.
 Cumulative Flow Diagrams (CFD’s)
Stack graphs that show how work is Progressing.

Cumulative Flow Diagrams (CFD’s)

Bottlenecks and Theory of Constraints

Cumulative Flow Diagrams (CFD’s)

Bottlenecks and Theory of Constraints
 Agile Contracting

 Agile’ s flexibility creates difficulty in outlining contract acceptance criteria

 Agile attempts to fix resources and time (cost) and vary functionality.

 “Customer collaboration over contract negotiation”

 Close cooperation
 Active participation
 Timely and often feedback

 Money for nothing and change for free.

 Graduated Fixed Price Contract

 Buyer / Seller share in risks and rewards
 Different hourly rates based on:
 Finish early, Finish on time, Finish late

 Fixed Price Work Packages

 Mitigate risks of under/overestimating.

Verifying and Validating Value
“Gulf of Evaluation”

 What one person describes is often different from how another interprets

Frequent Verification and Validation

Resolve problems as soon as possible.
Don’t let little problems grow over time.
 Stakeholder Engagement
DOMAIN 3

Stakeholder Stewardship
 Looking after everyone involved in the project.
 Ensuring everyone has everything they need to complete the project successfully.
 Starts with identifying the stakeholders.

Educating People about Agile

Teach all the stakeholders about the benefits of agile.
Concerns about agile can Include:
 Senior management and sponsor: They are worried about the risk of failing.
 Managers: fear the loss of control
 Project team: resist agile methods.
 Users: will not get all features.
Engaging Stakeholders
 Short iterations and release keep them engaged.
 Keeping then engaged can lead to stakeholders being more involved and getting more change request
 This helps us to identify risk and issues early.
 If some stakeholders are causing problems, the agile PM will need to use their interpersonal skills to
resolve issues.
 Need to have a process for escalating stakeholder’s issues.
 Why such a big focus on stakeholders?
o Projects and done by people for people.
 Methods of Stakeholder Engagement
 Get the right stakeholders.
 Cement stakeholder involvement
 Actively manage stakeholder interest
 Frequently discuss what done looks like
 Show progress and capabilities.
 Candidly discuss estimates and projections
Set a Shared Vision

Important to ensure customers and agile project team has the same vision.
Methods include:
o Agile Charter
o Definition of “Done”
o Agile Modeling
o Use case diagram.
o Data models
o Screen design
o Wireframes
o Personas
Agile Chartering
 High-level (uses the W5H)
 Agreement
 Authority to proceed.
 Focuses on how project will be conducted.
o Allows for flexibility and ability to deal with change.
 Project specific processes outlined.
 May use project Tweet – Describes project goal in 140 Characters or less.

Definition of “Done”
Creating a shared vision of what done looks like
Should be done for:
o User stories
o Releases
o Final project deliverables

Agile Modeling

Different modeling techniques that are used to help establish the shared vision
Should be lightweight or “barely sufficient.”
o Use case diagrams Visually shows how users would use an application.
 https://en.wikipedia.org/wiki/Use_case_diagram

 Data models
o How the data are structured in tables and their Relationships

http://www.agiledata.org/essays/dataModeling101.html

 Screen designs
o Simple screen shots
http://agilemodeling.com/artifacts/uiPrototype.htm

Wireframes
Wireframes:

 Quick mock-up of product

 “Low-fidelity prototyping”
 Clarify what “done” looks like
 Validate approach prior to execution.

Personas
Personas:
 Quick guides or reminders of key stakeholders and interests
o Provide description of users
o Be grounded in reality.
o Be goal-oriented, specific, and relevant.
o Be tangible and actionable.
o Generate focus.
 Help team focus on valuable features to users.
 Communicating with Stakeholders
 Face to face communication
 Two-way communication
 Knowledge sharing
 Information Radiators
 Social Media
Face-to-face Communication
Face to face communication

http://www.agilemodeling.com/essays/communication.htm
 Communicating with Stakeholders
 Two-way communication
o Just don’t ask for confirmation or concerns, but actually listen to what they have to say
 Knowledge sharing
o Agile teams work closely with each other such.as with pair-programming.
o Using Kanban boards or wireframes are ways to share information
o Use of low-tech tools like a whiteboard will allow all to see the work and understand it
o We must encourage it.
 Information Radiators
o Things that are highly visible
o Used to display information.
o Usually includes charts, graphs and boards.
 Social Media
o Use to communicate.
o Can include twitter or Instagram.

Green Zone/Red Zone

Red Zone:
o Blames others for everything.
o Responds defensively.
o Feels threatened.
o Triggers defensiveness.
o Doesn’t let go or forgive.
o Uses shame and blame.
o Focus on short-term advantage.
o Doesn’t seek or value feedback.
o Sees conflict as a battle and only seeks to win.
o Communicates high level of disapproval.
o Sees others as the problem or enemy.
o Does not listen effectively.

Green Zone:
o Take responsibility.
o Seeks to respond nondefensively.
o Is not easily threatened psychologically.
o Attempts to build success.
o Uses persuasion rather than force.
o Thinks both short and long term.
o Welcomes feedback.
o Sees conflict as a natural part of life.
o Seeks excellence rather than victory.
o Listen well.
Using Workshops
Meeting when work gets done.
Retrospectives are a type of workshop.
Ways to make them more effective:
o Diverse groups has a larger perspective
o Use methods such as round-robin to ensure no one dominates.
o Try to get everyone to participate in the first few minutes.

User story workshops are where we write the

user stories and keep stakeholders engage
 Brainstorming
Brainstorming:

Quite Writing
o Give people about 5 minutes to write down their ideas.
Round-Robin
o Pass a token around to ensure everyone will speak.
Free-for-all
o People shout out their thoughts. May only work in a supportive environment.
Collaboration Games
 Remember the future.
 Prune the product tree.
 Speedboat (Sailboat)
Remember the future.

 Ask stakeholders to imagine that an upcoming release was successfully and to look back.
 Gets a better understanding of how a stakeholder would define success.
 Outlines how we can accomplish that success for Them.

Prune the Product Tree

 Draw a tree and ask stakeholders to add their features to it
 Use stick notes to have them place new features on the tree.
 Group the features on the trunk.
 Features that are depending on other features would be higher up the tree.
 Lets everyone understand the priorities of Development.

Speedboat (Sailboat)
 Draw a waterline and a boat moving.
 Explain the boat is moving toward the goals of the project.
 Ask them to use sticky notes to show what can make the boat move (wind) and what can stop it
(anchors)
 Allows stakeholders to identify threats and Opportunities.

Using Critical Soft Skills

 Emotional intelligence
 Negotiation
 Active Listening
 Facilitation
 Conflict Resolution
 Participatory Decision Models
Emotional intelligence

 Our skill to identify, assess, and influence the emotions of ourselves and others around us
 We need to recognize our own feelings.
 Then we can learn how to response to others and how they feel
 Understanding how we take care of ourselves will impact other around us.
 As an agile PM we have to know when team members are stuck, angry, or frustrated.
 Negotiation
 This happens all throughout the project.
 Good negotiation will allow everyone to investigate the options and trade-offs.
 Most effective when interactions between people are positive and there are room for give and take.

Active Listening

 Level 1: Internal – how is it going to affect me.

 Level 2: Focused – put ourselves in the mind of the speaker
 Level 3: Global – builds on level with body Language.

Facilitation

Run effective meetings and workshops.

Have the following:
o Goals
o Rules
o Timing
o Assisting
Conflict Resolution

All projects will have conflicts, While some level of conflicts are good, we need to
ensure they don’t become a “world war” where people are trying to destroy each other
o Levels of conflict (1-5):
o Level 1: Problem to solve – sharing info
o Level 2: Disagreement – Personal Protection
o Level 3: Contest – Must win
o Level 4: Crusade – Protecting one’s group
o Level 5: World War – Must destroy the other
o
Participatory Decision Models
Engage stakeholder in decision making process
Simple voting:
o Vote “for” or “against” it
Thumps up/down/sideways:
o People hold their thumps in a way of if the support it or not. Sideway is if they cannot make up their
mind
Fist of five:
o People how up finger based on they support the idea
o 1 finger: total support – 5 finger: Stop against it

Team Performance
People Over Processes
Projects are done by people, not tools.
o Agile manifesto: “Individuals and Interactions over processes and tools”
Focus on the people side of the project.
Projects are more about people management than tools management.
People Over Processes
COCOMO
 o Constructive Cost Model
o To determine correlation between project input variables and final cost to use to estimate future
projects.
o People factors has a score of 33…11 times more significant than tools and processes.
COCOMO II

Development/Delivery Team

Group that build and test the increments of the product:

o Build product in increments.

o Update information radiators.
o Self-organize and directing.
o Share progress by doing daily stand-up meetings.
o Write acceptance tests.
o Demo the completed product increments.
o Holds retrospectives at the end of sprints.
o Does release and sprint planning and estimations.

Product Owner/Customer
o Prioritizing the product features
o Manage the product backlog ensuring its accurate and up to date.
o Ensures the team has a shared understanding of the backlog items.
o Defines the acceptance criteria.
o Provides the due dates for the releases.
o Attends planning meeting, reviews, and the retrospective.

Agile Project Manager (ScrumMaster/Coach)

o Act as a servant leader
o Help the team self-organize and direct themselves.
o Be a facilitator.
o Ensure the team plan is visible and the progress is known to the stakeholders.
o Act as a mentor and coach
o Work with the product owner to manage the product backlog.
o Facilitates meeting.
o Ensure issues are solved.
Building Teams
 Self-Organizing
 Self-Directing
 Small teams with fewer than 12 members

Generalizing Specialists

 Have members that can do different tasks.

 Members skilled in more than one area
 Share work reduce bottleneck.

High-Performance Agile Teams

 Have a shared vision.
 Realist goals
 Fewer than 12 members
 Have a sense of team identity.
 Provide strong leadership.

Experiments (Have a safe place)

 Establish a safe environment for disagreement.
 Allows team members to build strong commitment to decisions.
 Encourage people to experiment with new methods.
 Leads to more engagement.
 Welcome Constructive Disagreement

 Leads to better buy-in and decisions.

 Avoiding conflicts can lead to conflicts escalating.
 A safe place for disagreement leads to successful problem solving.

Models of team development

Shu-Ha-Ri Model of Skill Mastery
o Shu- Obey,
o Ha – Moving away,
o Ri – finding individual paths.
Dreyfus Model of Adult Skill Acquisition
o Novice, Advanced Beginner, Competent, Proficient, Expert
o
Tuckman’s Five Stages of Team Development
1. Forming: a team comes together and starts to get to know each other. There is not much conflict or
communication.
2. Storming: team members start to have conflicts with each other. They start to learn of each other’s ideas and
may not agree with them. Most conflicts take place in this stage.
3. Norming: the team members begin to agree with each other on the best methods to build the deliverables.
Generally, everyone comes to a consensus.
4. Performing: the team is performing well and is working without conflict.
5. Adjourning: In this stage, the project is completed, and the team is reassigned.
Adaptive Leadership

Concept of adapting how we lead team based on

specific circumstances and how mature team is in formation.

Training, Coaching, and Mentoring

Training
o Teaching of skills or knowledge
Coaching
o Process that helps a person develop and improve their skills.
Mentoring
o More of a professional relationship that can fix issues on an as needed basis.

Help the team stay on track, overcome issues, and continually improve skills.
Individual level
Whole-team level
 Team Spaces
 Co-located Teams
 Team Spaces
 Osmotic Communication
 Global and Cultural Diversity
 Distributed teams
Co-Located Teams

 All team members work together in the same location.

 Allows for face-to-face time and interaction.
 Should be within 33 feet of each other.
 No physical barriers
 Sometimes a virtual co-location
Team Space
Lots of low-tech, high touch
o Whiteboards and task boards
o Sticky notes, flip charts
o Round table
o No barriers to face-to-face communication
Caves and Common
o Caves > space team members can retreat to individually.
o Common > space team members can work as group.
Osmotic Communication
o Information flows that occur as part of everyday conversations and questions
o 33 feet or 10 meters
Tacit Knowledge
o Information that is not written down; supported through collective group knowledge.
o
Global and Cultural Diversity
I. Time Zones
II. Cultures
III. Native Languages
IV. Styles of communications
Distributed Teams

At least one team member working off-site.

Need to find ways to replicate co -location team benefits.
Agile Tools
o Low-Tech, High-Touch Tools
o Digital Tools for distribution teams.
o Video conferencing
o Interactive whiteboards
o IM / VoIP
o Virtual card walls
o Web cams
o Digital cams
 Tracking Team Performance
Burn Charts:
o Burnup
o Burndown
Velocity Charts
Burnup Chart

Work that has been done

Burndown Chart

Work that remains to be done

Velocity Charts
 Velocity Charts
If a team has completed 3 iterations with the average velocity of 18 points per iteration, how many iterations
would it take to complete 250 points of work?
=250/18 = About 14 more iterations.
Adaptive Planning
Adaptive Planning
o Planning is an ongoing process.
o Multiple mechanisms to proactively update plan.
o Focus on value delivery and minimize nonvalue adding work.
o Uncertainty drives need to be replanted.
o Frequently discover issues and experience high rates of change
Agile Plans
Agile planning varies from traditional planning.
1. Trial and demonstration uncover true requirements, which then require planning
2. Agile planning is less of an upfront effort, and instead is done more throughout the project
3. Midcourse adjustments are the norm

Principles of Agile Planning

1. Plan at multiple levels
2. Engage the team and the customer in planning
3. Manage expectations by frequently demonstrating progress
4. Tailor processes to the project’s characteristics
5. Update the plan based on the project priorities
6. Ensure encompassing estimates that account for risk, distractions, and team availability
7. Use appropriate estimate ranges to reflect the level of uncertainty in the estimate
8. Base projections on completion rates
9. Factor in diversion and outside work

Progressive Elaboration

Adding more detail as information emerges

Includes:
o Plans
o Estimates
o Designs
o Test scenarios
Rolling wave planning: Planning at multiple
points in time as data becomes available.

Value-Base Analysis and Decomposition

 Assessing and prioritizing the business value of work items, and then plan accordingly.
 Consider payback frequency and dependencies.
 Value -Based Decomposition
o Breaks down requirements and prioritizes them.
o Design the product box.
 Design the Product Box

“Coarse-Grained” Requirements

 Keep Requirements “coarse” then progressively refine them.

 Helps keep the overall design balance.
 Delays decision on implementation until the “last responsible moment”
Timeboxing
Short, fixed-duration periods of time in which activities or work are undertaken.
o If work is not completed within time period, move it to another timebox.
Daily Stand-up – 15 minutes
Retrospectives – 2 hours
Sprints – 1-4 weeks
Beware of Parkinson’s Law
o Work tends to expand to fill the time given.

Agile Estimation

Knowledge of agile estimation theory & ability to perform simple agile estimating
techniques.
Why do we estimate?
o Determining which pieces of work can be done within a release or iteration.
How are estimates created?
o By progressing through the stages planning.
How should estimates be stated?
o Should be started in ranges.
When do we estimate?
o Throughout the project. More detail in the later parts of the project
Who estimates?
o Team members will do their own estimates.

Ideal Time

Refers to the time it would take to complete a given task assuming zero interruptions or unplanned
problems.
 Decomposing Requirements

User Stories
User Stories / Backlogs
• Business functionality within a feature that involves1-3 days of work.
• Acts as agreement between customers and development team
• Every requirement is user story
• Every story, including technical stories, has value
• Common structure of a user story

User Story Example

“As a payroll clerk, I want to be able to view a report of all payroll taxes, so that I can pay them on
time”.
“As a sales person, I want to be able to see a current list of leads, so that I can call them back quickly”
“As student of this course, I want to be able to understand the requirements of the exam, so that I
know if I qualify for it or not.”
Three C’s of Stories
Have users write the stories on index cards.
No details, it’s used to help conversate.
3 Cs:
o Card
o Conversation
o Confirmation
User Stories – INVEST

Effective user stories should be “INVEST”.

Independent
o Should be independent so it can reprioritize.
Negotiable
o Should allow for trade-off’s based on cost and function.
Valuable
o Should clearly state the value of it.
Estimable
o Should be able to estimate how long to complete.
Small
o Stories should be between 4-40 hours of work.
Testable
o Should be testable to ensure it will be accepted once Competed.
User Story Backlog (Product Backlog)
Prioritize Requirements
Refining (Grooming) Backlog
o Keeping the backlog updated and accurately prioritized.

Relative Sizing and Story Points

o Absolute estimates are difficult for humans to make.
o Estimates should be relative.
o Assign points to each story using a relative Numbers.

Fibonacci Sequence

https://en.wikipedia.org/wiki/Fibonacci_number
Fibonacci Sequence: 1, 2, 3, 5, 8, 13, 21
Guidelines for Using Story Points
 Team should own the definition of their story points.
  Story point estimates should be all-inclusive.
 Point sizes should be relative.
 Complexity, work effort, and risk should all be included in the estimate.
Affinity Estimating and T-Shirt Sizing
Affinity Estimating
o Group estimates into categories or collections
T-Shirt Sizing
o Place stories in sizes of t-shirts
Wideband Delphi
Wideband Delphi
o Group-based estimation approach
o Panel of experts, anonymously
It’s used to prevent:
o Bandwagon effect
o HIPPO decision making (HIghest-Paid Person's Opinion)
o Groupthink
Planning Poker

Advantages of Wideband Delphi Fast, collaborative process Uses cards with Fibonacci sequence.
Story Maps
 High-level planning tool
 Stakeholders map out what the project priorities are early in the planning.
 Serves as the “product roadmap”.
 Shows when features will be delivered and what is included in each release.

Product Roadmap

 Shows when features will be delivered and what is included in each release.
 Can convert the story map into a product roadmap.

Types of Iterations
Iteration 0
o Set the stage for development efforts.
o Doesn’t build anything.
Development Iteration
o Build the product increment. Iteration H (hardening sprint or release)
o Done at the end to clean up codes or producing documentation.

Spikes
  Architectural spike
o Period of time dedicated to proof of concept.
 Risk-Based Spike
o Team investigates to reduce or eliminate risk.
o
Iteration Planning
 Meeting run by the delivery team.
 Discuss the user stories in the backlog.
 Select the user stories for the iteration.
 Define the acceptance criteria.
 Break down the user stories into tasks.
 Estimate the task.
Release Planning
Meeting with all stakeholders to determine which stories will be done in which iterations for the
upcoming release.
Selecting the user stories for the release
o Using Velocity – points per iteration
Slicing the stories
o Breaking down stories that are too large to be completed in 1 iteration.
Problem Detection and Resolution

Understand How Problems Happen

o All projects will have problems.

o As a project is progressing the agile PM should expect issues to happen
o Overtime issues can delay or change a project objective.

Cost of Change

Over time the cost of change will increase

 Cost of Change

Technical Debt.

 Backlog of work caused by not doing regular cleanup.

 If not done will lead the increase cost of development and make it harder to implement changes
 Refactoring is the solution.
Failure Modes
Why do people Fail:
1. Making mistakes
2. Preferring to fail conservatively
3. Inventing rather than researching
4. Being creatures of habit
5. Being inconsistent
Success Modes
Why do we succeed:
1. Being good at looking around
2. Being able to learn
3. Being malleable
4. Taking pride in work
Success Strategies
 Balance discipline with tolerance
 Start with something concrete and tangible.
 Copy and alter.
 Watch and listen.
 Support both concentration and communication.
 Match work assignment with the person.
 Retain the best talent.
 Use rewards that preserve joy and combine rewards.
 Get feedback.
Lead Time and Cycle Time
Lead/Cycle time
o Lead time: how long something takes to go through the entire process.
o Cycle time: how long something takes to go through a part of the process. Part of lead time.
Cycle Time
 Measure how long it takes to get things done.
 Closely related to work in progress (WIP)
 Excessive WIP is associated with several problems.
 Represents money invested with no return on investment yet.
 Hides bottlenecks in processes & masks efficiency issues.
 Represents risk in form of potential rework.
Cycle Time.
 Long cycle times lead to increased amounts of WIP.

 Throughput: Amount of work that can done in a time period

Cycle Time Question
What would be the cycle time of feature A, if it requires 60 points of work and the team can complete 5 points
per day?
=60/5 points per day = 12 days.
Defects
The longer defects are left, the more expensive to fix.
More work may have been built on top.
of bad design, resulting in more work to be undone.
Later in development cycle, more stakeholders impacted by defect and more expensive to fix
Escaped Defects
o Defects that make it to the customer
Variance and Trend Analysis
Variance measure of how far apart things are (or vary)
Trend Analysis measure that provides insight into future issues
o Lagging Metrics provides information on something that has already happened.
o Leading Metrics provides information on is or is about to occur.
Control Limits
 Help diagnose issues before an issue occurs.
 Provide guidelines to operate within
Risk
Risk Adjusted Backlog
o Adjusting the backlog for risk
o Done after risk response.
Expected Monetary Value = Impact ($) x Probability(%)
Risk Severity
o Risk Probability x Risk Impact
o Uses a scale of numbers (E.g 1-5)
Risk Burndown Graphs
 Solving Problems
 Problem Solving as continuous improvement.
 Engage the team.
 Some problems can’t be solved.

Why Engaging the Team?

Team usually produces the best practical solutions.
Benefits
o Get consensus from all members.
o Gets a broad knowledge base.
o Solutions are practical.
o When ask people work hard to produce good ideas.
o Asking someone for help shows confidence.
Usage and Cautions
o Solve real problems.
o Poor team cohesion
o Team and project changes
o Follow-Through
Continuous Improvement
Kaizen
o Kaizen is a process for continuous improvement name after the Japanese word.
o Focus on the team to implement small incremental improvement.
o Usually follows the Plan-Do-Check-Act (PDCA) cycle by Edwards Deming
PDCA
 Agile Cycle

Process Analysis
 Review and diagnose issues.
 Look for tailoring possibilities.

Process Tailoring
 Amend methodology to better fit project environment.
 Change things for good reason, not just for sake of change.
 Develop a hybrid.
Value Stream Map
Optimize the flow of information or materials to complete a process.
Reduce waste (waiting times) or unnecessary work.

Steps to creating:
o Identify the product or service.
o Create a value stream map.
o Review to find waste.
o Create a new map with the desire improvement.
 o Develop a roadmap to implement the fixes.
o Plan to revisit it again.
Value Stream Map Example

Pre-Mortems

Team meeting that looks at possible things that can cause failure during a project before they take
place.
Steps include:
 Think what the failures might be.
 Create a list of reasons that can cause the failures.
 Review the project plan to determine what can be done to reduce or remove the reasons for failure.

Retrospectives
 Special meeting that takes place after each iteration
 Inspect and improve methods and teamwork.
 Offers immediate value.
 Should have a 2-hour time limit.
Retrospectives Stages

About 2 Hours for a typical retrospective

1. Set Stage – 6 Minutes
2. Gather Data – 40 Minutes
3. Generate Insights – 25 Minutes
4. Decide What to Do – 20 Minutes
5. Close Retrospective – 20 Minutes
1. Set the Stage
 Start of the retrospective
 Help people to get focused.
 Encourage participation to ensure everyone starts talking early.
 Outlining the approach and topics for discussion
 Get people in the mood for contributing information.
Activities include:
o Check-In
o Focus On/Focus Off
o ESVP
 o People identify if they are an explorer, shopper, vacationer, or Prisoner.
2. Gather Data
Create a picture of what happened during the sprint.
Start to collect information to be used for improvement.
Activities:
o Timeline
o Triple Nickels: break the team into 5 groups to spend 5 minutes collecting 5 ideas, 5 time.
o Mad, Sad, Glad: what where the team emotion as the sprint was taking place.

3. Generate Insights
Analyze the data.
Helps to understand what was found.
Activities Include:
o Brainstorming
o Five Whys: asking why five times
o Fishbone analysis
o Prioritize with dots: use a dot voting technique.
o
Fishbone Analysis

4. Decide what to do.

Decide what to do about the problems that were found.

How can we improve for the next iteration.
Activates include:
 Short Subjects
 Smart Goals
 Short Subjects

Team decides what actions to take in the next iteration:

 Start doing.
 Stop doing.
 Do more of
 Do less of
SMART Goals
Team sets goals that are SMART:
 Specific
 Measurable
 Attainable
 Relevant
 Timely
5. Close the Retrospective

Opportunity to reflect on what happened during the retrospective.

Activities include:
o Plus/Delta: make two columns of what the team will do more of and what to do less of
Team Self-Assessments

Uses to evaluate the team as a hold.

Things to evaluate can include:
o Self-organization
o Empowered to make decisions.
o Belief in vision and success
o Committed team.
o Trust each other
o Constructive disagreement