Agile Slides

Agile Principles and
Mindset
What is Agile
Developed for Software projects, but it is a
methodology that can be used on all Projects
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 Project Management, ©TIA Education Group. DO NOT SHARE.

Characteristics of four life cycles
PMI Agile Practice Guide, Page 18 table 3.1

Agile leverage
both aspect of
Iterative and
incremental

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,
redirect or 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 for 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.
©2005 David Anderson, Sanjiv Augustine, Christopher Avery, Alistair Cockburn, Mike Cohn, Doug
DeCarlo, Donna Fitzgerald, Jim Highsmith, Ole Jepsen, Lowell Lindstrom, Todd Little, Kent
McDonald, Pollyanna Pixton, Preston Smith and Robert Wysocki.

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

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 sees value faster vs. at the end
Agile wants changes vs. discouraging changes

Inverting the Triangle
Fixed
Time Cost
Scope
Agile
Traditional Scope
Time Cost
Variable

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:
Individuals & interactions over Processes & tools
Comprehensive
Working software over
documentation
Customer collaboration over Contract negotiation
Responding to change over Following a plan
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 delivering value vs. paperwork.

Agile documents should be barely sufficient
Done just in time
Done just because
Delivering software that does what it should
comes first, before creating documentation.
Agile dramatically simplify 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

Agile Guiding Principles
1-3
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-6
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-9
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-12
10. Simplicity; the art of maximizing the amount
of work not done is essential.
11. The best architectures, 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
Many agile methodologies
Scrum
Extreme Programming (XP)
Kanban Development
Lean Software Development
Scaled Agile (SAFe)

Agile Scrum 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 provides feedback. This feedback adjust the next Sprint priorities
Release - Several Sprints worth of work directed to operations for possible rollout and testing
Sprint = Iteration

Agile Scrum Process
Product Sprint Sprint

Customers/Product Planning
Sprint/Iteration
Ownwer Backlog Backlog
Meeting
Potentially Sprint Sprint Review

Shippable Product REtrospective Meeting
Increment

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
ScrumMaster
◦ Responsible for facilitating process
◦ Focuses Team and protects them from external
interruption
◦ Looks for ways to enhance productivity
◦ Assists Product Owner in leveraging Scrum

Scrum Roles &
Responsibilities
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 needs
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

XP Core Values
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 stay 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 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,
XP Practices
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

XP Practices
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

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

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

XP Practices
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 architectures, 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
Extreme
Scrum Definition
Programming (XP)
Fixed-length period of time
Sprint Iteration
(timebox)
Release Small Release Release to production
Sprint/Release
Planning Game Agile planning meetings
Planning
Business representative to
Product Owner Customer
project
Retrospective Reflection “Lessons learned”-style meeting
ScrumMaster Coach Agile project manager

Development Empowered Cross-Functional
Team
Team team
Daily Scrum Daily Standup Brief daily status meeting

Lean Software
Development
Lean was started by Toyota as 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
Eliminate
Waste
Amplify Empower
Learning the team
Lean
Defer Deliver
Decisions Fast
Optimize
Build
the
Quality In
Whole

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."
Items In Progress Testing Done
6 cards 4 cards

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.

Other agile methods
Feature-Driven Development
◦ Team will first develop an overall model
for the product then build a list, and
plan the work.
Crystal
◦ It’s a customized methodologies that
are coded by color names.
◦ Crystal clear is for small teams working
on non-critical projects
◦ Crystal magenta is used for larger teams
working on more critical work

Other agile methods
Scalable Agile Framework (SAFe®)
◦ A framework that implements Scrum at an
enterprise level
◦ Approach that consumes the whole enterprise
and not just a team
◦ Deals with big global teams
◦ All aspect of the organizations are managed
◦ Three important parts:
◦ Lean Product Development
◦ Agile Software Development
◦ System Thinking

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
©2002 Jeffery Pinto, Project Leadership from Theory to Practice

Twelve Principles for
Leading Agile Projects
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 need 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
Crate a safe environment for
experimentation
Experiment with new techniques and
processes
Share knowledge through collaboration

Value-Driven Delivery
HowPrioritization
Planning Value – Value Based Customers Conduct
Value Prioritization
Valued based prioritization is the one of core
practices in agile planning
Features are prioritized on the basis of
business value, risk and dependencies
Some of prioritization techniques used:
◦ Simple Scheme
◦ MoSCoW prioritization
◦ Monopoly Money
◦ 100-point method
◦ Dot Voting or Multi-voting
◦ Kano Analysis
◦ Requirements Prioritization Model
2 Agile Project Management, ©TIA Education Group. DO NOT SHARE.

Prioritization
Techniques
Simple Scheme
◦ Priority 1, Priority 2, Priority 3, etc.
◦ Could be problematic as many items
might become the first priority.
MoSCoW prioritization
◦ Must have
◦ Should have
◦ Could have
◦ Would like to have, but not this time

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

Prioritization
Techniques
Kano Analysis
◦ Helps to understand the customers
satisfaction
◦ Delighters/Exciters
◦ Satisfiers
◦ Dissatisfiers
◦ Indifferent
https://foldingburritos.com/kano-model/

Prioritization /
Ranking is Relative
Doesn’t matter what techniques the
customers 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, its 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 functionality 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:
◦ Data accuracy perception increases
◦ No stakeholder interaction. Only a few
people would update them

Low-Tech, High-
Touch Tools
Use card, 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
Items In Progress Testing Done
6 cards 4 cards

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 keeps them
engage
Keeping then engage 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
stakeholders issues
Why such a big focus on stakeholders?
◦ 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:
◦ Agile Charter
◦ Definition of “Done”
◦ Agile Modeling
◦ Use case diagram
◦ Data models
◦ Screen design
◦ Wireframes
◦ Personas

Definition of “Done”
Creating a shared vision of what done
looks like
Should be done for:
◦ User stories
◦ Releases
◦ Final project deliverables

Agile Modeling
◦ Use case diagrams
◦ Visually shows how users would use an application
https://en.wikipedia.org/wiki/Use_case_diagram

Agile Modeling
◦ Data models
◦ How the data are structured in tables and their
relationships
http://www.agiledata.org/essays/dataModeling101.html

Agile Modeling
◦ Screen designs
◦ 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
◦ Provide description of users
◦ Be grounded in reality
◦ Be goal-oriented, specific, and relevant
◦ Be tangible and actionable
◦ Generate focus
◦ Help team focus on valuable features to users

Personas
Name: Andrew Jones– Certified Accountant
Value:
Andrew would like to ensure all
company bills are paid on time
while using online auto payments.
Description: He would like to ensure customers
Andrew has been an Accountant are reminded automatically of
for over 10 years and has worked at outstanding balances.
many large accounting firms.
He is looking to print the
He likes to be organized and get his receivables and payable reports on
work done on time. a weekly basics to check on bills
and invoices.

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
◦ Just don’t ask for confirmation or concerns, but
actually listen to what they have to say
Knowledge sharing
◦ Agile teams work closely with each other such
as with pair-programming.
◦ Using Kanban boards or wireframes are ways to
share information
◦ Use of low-tech tools like a whiteboard will
allow all to see the work and understand it
◦ We must encourage it

Communicating with
Stakeholders
Information Radiators
◦ Things that are highly visible
◦ Used to display information
◦ Usually includes chats, graphs and boards
Social Media
◦ Use to communicate
◦ Can include twitter or Instagram

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
Levels of conflict(1-5):
◦ Level 1: Problem to solve – sharing info
◦ Level 2: Disagreement – Personal Protection
◦ Level 3: Contest – Must win
◦ Level 4: Crusade – Protecting one’s group
◦ Level 5: World War – Must destroy the other

Participatory
Decision Models
Engage stakeholder in decision making
process
◦ Simple voting
◦ Vote “for” or “against” it
◦ Thumps up/down/sideways
◦ 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
◦ People how up finger based on they support the idea
◦ 1 finger: total support – 5 finger: Stop against it

Team Performance
Development /
Delivery Team
Group that build and test the increments
of the product
◦ Build product in increments
◦ Update information radiators
◦ Self organize and directing
◦ Share progress by doing daily stand-up
meetings
◦ Demo the completed product increments
◦ Holds retrospectives at the end of sprints
◦ Does release and sprint planning and
estimations

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

Agile Project Manager
(ScrumMaster/Coach)
Act as a servant leader
Help the team self-organize and direct
themselves
Be a facilitator
Ensure the team plan is visible and the
progress is known to the stakeholders
Act as a mentor and coach
Work with the product owner to manage
the product backlog
Facilitates meeting
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 safe environment for
disagreement
Allows team members to build strong
commitment to decisions
Encourage people to experiments 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
◦ Shu- Obey,
◦ Ha – Moving away,
◦ Ri – finding individual paths
Dreyfus Model of Adult Skill Acquisition

◦ Novice, Advanced Beginner, Competent,
Proficient, Expert

Tuckman’s Five
Stages of Team
Development
1. Forming: 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 takes
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 is coming 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.

Team Spaces
Co-located Teams
Team Spaces
Osmotic Communication
Global and Cultural Diversity
Distributed teams

Co-Located Teams
All team member 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
◦ Whiteboards and task boards
◦ Sticky notes, flip charts
◦ Round table
◦ No barriers to face-to-face communication
Caves and Common
◦ Caves  space team members can retreat to
individually
◦ Common  space team members can work as group
Osmotic Communication
◦ Information flows that occur as part of everyday
conversations and questions
◦ 33 feet or 10 meters
Tacit Knowledge
◦ Information that is not written down; supported
through collective group knowledge

Global and Cultural
Diversity
Time Zones
Cultures
Native Languages
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
◦ Low-Tech, High-Touch Tools
◦ Digital Tools for distribute teams
◦ Video conferencing
◦ Interactive whiteboards
◦ IM / VoIP
◦ Virtual card walls
◦ Web cams
◦ Digital cams

Adaptive Planning
Adaptive
Planning
Planning is ongoing process
Multiple mechanisms to proactively
update plan
Focus on value delivery and minimize
nonvalue-adding work
Uncertainty drives need to replan
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
replanning
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

Value-Base Analysis
and Decomposition
Assessing and prioritizing the
business value of work items,
and then plan accordingly.
Value-Based Decomposition
◦ Breaks down requirements and
prioritized them
◦ Design the product box

Design the
Product Box

Timeboxing
Short, fixed-duration periods of
time in which activities or work
are undertaken
◦ 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
◦ Work tends to expand to fill the
time given

Decomposing
Requirements

User Stories
User Stories / Backlogs
• Business functionality within a feature
that involves 1-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
As a <user type>
I <want to/need, etc.> goal
So that <value>

User Story Example
“As an 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:
◦ Card
◦ Conversation
◦ Confirmation

User Stories - INVEST
Effective user stories should be “INVEST”
Independent
◦ Should be independent so it can reprioritize
Negotiable
◦ Should allow for trade-off’s based on cost and
function
Valuable
◦ Should clearly state the value of it
Estimatable
◦ Should be able to estimate how long to complete
Small
◦ Stories should be between 4-40 hours of work
Testable
◦ Should be testable to ensure it will be accepted
once competed

User Story Backlog
(Product Backlog)
Prioritize Requirements
Refining (Grooming) Backlog
◦ Keeping the backlog updated and accurately
prioritized

Relative Sizing and
Story Points
Absolute estimates are difficult for
humans to make
Estimates should be relative
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
◦ Group estimates into categories or
collections
T-Shirt Sizing
◦ Place stories in sizes of t-shirts

Wideband Delphi
Wideband Delphi
◦ Group-based estimation approach
◦ Panel of experts, anonymously
It’s used to prevent:

◦ Bandwagon effect
◦ HIPPO decision making (HIghest-Paid
Person's Opinion)
◦ Groupthink

Planning Poker
Advantages of Wideband Delphi
Fast, collaborative process
Uses cards with Fibonacci sequence

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
◦ Set the stage for development efforts
◦ Doesn’t build anything
Development Iteration
◦ Build the product increment
Iteration H (hardening sprint or release)

◦ Done at the end to clean up codes or producing
documentation
Iteration Dev Dev Dev Dev Iteration

0 Iteration Iteration Iteration Iteration H

Spikes
◦ Architectural spike
◦ Period of time dedicated to proof of concept
◦ Risk-Based Spike
◦ Team investigate to reduce or eliminate risk

Tracking Team
Performance
Burn Charts
◦ Burnup
◦ Burndown
Velocity Charts

Burnup Chart
Work that has been done

Burndown Chart
Burndown Chart
Work that remains to be done

Velocity Charts
25
20
15
10
0
1 2 3 4 5 6 7 8 9 10 11 12
Iterations
Show how the team is performing

Velocity Charts
If a team has complete 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.

Continuous
Improvement
PDCA
Act Plan
Check Do

Agile Cycle
Plan
Learn Develop
Evaluat
e

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:
◦ Identify the product or service
◦ Create a value stream map
◦ Review to find waste
◦ Create a new map with the desire
improvement
◦ Develop a roadmap to implement the fixes
◦ Plan to revisit it again

Value Stream Map
Example
Get
Get
Call US Course Register Attend 44 Minutes
Certificate
2 Minutes
info 10 Minutes 12 Minutes 20 Minutes
Get Get
Call US Course Register Attend Certificat 15 Minutes
2 Minutes
info 5 Minutes 5 Minutes 3 Minutes
e

Retrospectives
Special meeting that takes place after
each iteration
Inspect and improve methods and team
work
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 focus
Encourage participation to ensure everyone
start talking early
Outlining the approach and topics for
discussion
Get people in mood for contributing
information
Activities include:
◦ Check-In
◦ Focus On/Focus Off
◦ ESVP
◦ 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:
◦ Timeline
◦ Triple Nickels: break the team into 5
groups to spend 5 minutes collecting 5
ideas, 5 time
◦ 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:
◦ Brainstorming
◦ Five Whys: asking why five times
◦ Fishbone analysis
◦ Prioritize with dots: use a dot voting
technique

Fishbone Analysis
Work/Famaily Exam
Distraction from studying Anxiety
Cold/Hot exam room

Too much work
Run out of time
Fail PMP Exam
Lack of
Lack of
Wrong material

4. Decide what to
do
Decide what to do about the
problems that was 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:
◦ Plus/Delta: make two column of what the
team will do more of and what to do less
of

Agile Slides

Uploaded by

Copyright:

Available Formats

Agile Slides

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Agile Slides

Uploaded by

Copyright:

Available Formats

Agile Principles and

Agile Project Management, ©TIA Education Group. DO NOT SHARE.

PMI Agile Practice Guide, Page 18 table 3.1

Agile Project Management, ©TIA Education Group. DO NOT SHARE.

Agile Project Management, ©TIA Education Group. DO NOT SHARE.

Agile Project Management, ©TIA Education Group. DO NOT SHARE.

Agile Project Management, ©TIA Education Group. DO NOT SHARE.

Agile Project Management, ©TIA Education Group. DO NOT SHARE.

Agile builds in increments vs. as a whole

Agile Project Management, ©TIA Education Group. DO NOT SHARE.

Agile Project Management, ©TIA Education Group. DO NOT SHARE.

Agile Project Management, ©TIA Education Group. DO NOT SHARE.

Individuals & interactions over Processes & tools

Customer collaboration over Contract negotiation

Responding to change over Following a plan

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

Agile Project Management, ©TIA Education Group. DO NOT SHARE.

While processes and tools will likely be necessary on

Agile Project Management, ©TIA Education Group. DO NOT SHARE.

Focus on the delivering value vs. paperwork.

Agile Project Management, ©TIA Education Group. DO NOT SHARE.

Be flexible and accommodating, instead of fixed

Agile Project Management, ©TIA Education Group. DO NOT SHARE.

Spend effort and energy responding to changes

Agile Project Management, ©TIA Education Group. DO NOT SHARE.

1. Our highest priority is to satisfy the customer

Agile Project Management, ©TIA Education Group. DO NOT SHARE.

Agile Project Management, ©TIA Education Group. DO NOT SHARE.

Agile Project Management, ©TIA Education Group. DO NOT SHARE.

Agile Project Management, ©TIA Education Group. DO NOT SHARE.

Agile Project Management, ©TIA Education Group. DO NOT SHARE.

Agile Project Manager/Scrum Master – Manages the agile project

Product Backlog - Project requirements from the stakeholders

Agile Project Management, ©TIA Education Group. DO NOT SHARE.

Product Sprint Sprint

Potentially Sprint Sprint Review

Agile Project Management, ©TIA Education Group. DO NOT SHARE.

Agile Project Management, ©TIA Education Group. DO NOT SHARE.

Agile Project Management, ©TIA Education Group. DO NOT SHARE.

Agile Project Management, ©TIA Education Group. DO NOT SHARE.

3. sprint review meeting

Agile Project Management, ©TIA Education Group. DO NOT SHARE.

Agile Project Management, ©TIA Education Group. DO NOT SHARE.

Agile Project Management, ©TIA Education Group. DO NOT SHARE.

Agile Project Management, ©TIA Education Group. DO NOT SHARE.

Agile Project Management, ©TIA Education Group. DO NOT SHARE.

Agile Project Management, ©TIA Education Group. DO NOT SHARE.

Agile Project Management, ©TIA Education Group. DO NOT SHARE.

Agile Project Management, ©TIA Education Group. DO NOT SHARE.

Agile Project Management, ©TIA Education Group. DO NOT SHARE.

Agile Project Management, ©TIA Education Group. DO NOT SHARE.

Agile Project Management, ©TIA Education Group. DO NOT SHARE.

Software development centric agile method

Agile Project Management, ©TIA Education Group. DO NOT SHARE.

Agile Project Management, ©TIA Education Group. DO NOT SHARE.

Agile Project Management, ©TIA Education Group. DO NOT SHARE.

Agile Project Management, ©TIA Education Group. DO NOT SHARE.

Collective Code Ownership:

Agile Project Management, ©TIA Education Group. DO NOT SHARE.