View
104
Download
3
Category
Tags:
Preview:
DESCRIPTION
Citation preview
Fundamentals of Agile
1 Day Course
1
Please do not copy or reproduce this course materials without expressed written consent from SparkAgility. Anyone who engage in unauthorized duplication of the course materials will be held duly accountable by the PMI Ethics Committee.
Notice
2
Warm Up & Introductions
Constella,on
Fast intro
What’s in it for me?
3
! Founder, Managing Consultant and Trainer
! Over 15 years of experience; business analysis, project management, team facilitation & development, process improvement and agile coaching
! Driven by helping individuals and teams reach their full potential
! Passionate about spreading agility to the community (PMI Agile Community of Practice, PMI local chapter and Meetups)
! Bachelors in Business / Accounting and Masters in Information Systems & Financial Management
! Project Management Professional (PMP), Agile Certified Practitioner (ACP), Certified Scrum Master (CSM), ICAgile Certified Professional in Agile Coaching & Facilitation (ICP-TC), Certified Trainer in Training from the Back of the Room
Salah Elleithy
@selleithy salah@sparkagility.com 4
410.262.5550
Our Backlog
5
Origins of Agile!
Agile Manifesto!
Agile beyond SW
Development!
Understand the Agile Mindset!
Establishing the Agile Mindset!
Developing Soft Skills!
Understanding Communication
Barriers!
Sharing Knowledge!
Collaboration Techniques!
Shift in roles!
Value based work!
Work in progress!
Our Backlog
6
Involving the customer!
Continuous Delivery!
Continuous Integration!
User involvement!
Involving the customer!
User feedback!
Planning!
Estimation!
Status (Tracking)!
Process adaptation!
Logistics
7
• As a participant:
– I will do my best to be on time so that I don’t miss any portion of the course
– I will be present physically and mentally so that I can retain more of what is covered
– I will do my best to maintain my focus on learning and participate so that I can get the most out of the course
– I will respect all participants thoughts and opinions so that I can benefit from others’ experience
Pledge of Learning
8
Roadmap
9
High Level Outcomes
Explore Agile history and mindset
Identify the difference between ‘being’ agile & ‘doing’ agile
Discover the importance of individuals and interactions
Apply different techniques for planning, estimation and tracking progress
Demonstrate the ability to adapt based on regular inspection and introspection
10
ICAgile Certified professional
www.sparkagility.com
What is the Problem
11
12
Gulf of Evaluation
13
IKIWISI (I’ll know it when I see it)
Biggest 14
Are
we
solv
ing
Right the
Problem?
15
Are we building
Solution?
" What problems are you trying to solve with Agile?
" Discuss with your table
Why Agile?
16 Timebox: 3 minutes
Better success rates
Credit: Mike Cohn
17
2004 2006 2008 2010 2012
Successful 29% 35% 32% 37% 39%
Failed 18% 19% 24% 21% 18%
Challenged 53% 46% 44% 42% 43%
Source: Standish Group CHAOS Manifesto 2013
Project resolution results
18
Source: Standish Group CHAOS Manifesto 2013
Success factors 1994 2011 2012 - 2013
1 User Involvement Executive management support
2 Executive Management Support Executive management support
User Involvement
3 Clear Statement of Requirements Clear business objectives
Optimization
4 Proper Planning Emotional maturity Skilled resources
5 Realistic Expectations Optimization Project management expertise
6 Smaller Project Milestones Agile process Agile Process
7 Competent Staff Project management expertise
Clear Business Objectives
8 Ownership Skilled resources Emotional Maturity
9 Clear Vision & Objectives Execution Execution
10 Hard-working, Focused staff Tools & Infrastructure Tools & Infrastructure
19
Source: VersionOne 7th Annual State of Agile Development Survey
Benefits of being Agile
20
Source: VersionOne 7th Annual State of Agile Development Survey
Reasons for failed Agile projects
21
Misconceptions about Agile
22
23
Origins of Agile
Crystal Methods (Alistair
Cockburn)
2001 and beyond Dynamic Systems Development
Methods (Arie van
Bennekum)
SCRUM (Ken Schwaber &
Jeff Sutherland
Feature Driven Development
(FDD) (Jon Kern)
Adaptive Planning (Jim Highsmith)
An Evolution in the making
24
Waterfall (Winston Royce
40 years ago
Declaration of Interdependence
Agile Manifesto Agility as a way
of thinking
I promise not to exclude from consideration any idea based on its source, but to consider ideas across schools and heritages in order
to find the ones that best suit the current situation. - Alistair Cockburn
Lean/Kanban
Source: Dr. Winston W. Royce
“I believe in this concept, but the implementation
described above is risky and invites failure.”
25
Source: Managing the development of large SoKware System, Dr. Winston W. Royce hRp://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf
“Hopefully, the iterative interaction between the
various phases is confined to successive steps.”
26
27
Agile Manifesto
Responding to change
Customer collaboration
Working software
Individuals and interactions
That is, while there is value in the items on the right, we value the items on the left more.
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Following a plan
Contract negotiation
Comprehensive documentation
Process and tools
Agile manifesto
28
" Find the Agile value that is most important to you " Stand by your value and share what made you choose this value " Report back to the group
Stand by your value
Agile Values
29 Timebox: 5 minutes
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.
Agile Principles
30
Agile Principles (cont.)
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 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.
31
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 share responsibility for team effectiveness.
# We improve effectiveness and reliability through situationally specific strategies, processes and practices.
Declaration of Interdependence (DOI)
Source: pmdoi.org
Declaration Of Interdependence
Project leaders!Signed by:
32 32
33
Agile beyond Software Development
$ Jim Highsmith: Agility is the ability to both create and respond to change in order to profit in a turbulent business environment.
$ Ahmed Sidky: Agility is the flexibility to navigate the constraints of your project to get the most value as quickly as possible.
Agility defined
34
Roadmap
35
Framework Discover
(build the right product)
Develop & Deliver (build the product right)
Build
Measure Learn
The Leanstartup Machine
Plan
Construct
IDEA CONSTRUCT SHIP
Agile Framework/Practices
Ship
Learn Charter, Backlog, Release plan
Code, test and deploy
36
Experience product or service
How can we work better? And deliver more value?
Build a game that facilitate information sharing and encourage learning for college students
Exercise
VISION
• High level design • Key Features (Minimally marketable features - MMF)
Outcomes
37 Timebox: 10 minutes
As you were working together to identify high level design and key features:
" What went well? " What needs
improvement?
Inspect & Adapt
Timebox: 5 minutes 38
39
Understanding the Agile mindset
Characteris:c Fixed Growth
Avoid Failure ☐ ☐
Con,nuous Learning ☐ ☐
Exert effort to learn ☐ ☐
Embrace challenges ☐ ☐
Ask for feedback ☐ ☐
Cri,cism is personal ☐ ☐
Look smart ☐ ☐
S,ck to what I know ☐ ☐
Not afraid to fail ☐ ☐
Cri,cism is about capabili,es ☐ ☐
Failure means lack of talent ☐ ☐
Ability
Growth vs. Fixed Mindset
40
Characteris:c Fixed Growth
Avoid Failure " ☐
Con,nuous Learning ☐ "
Exert effort to learn ☐ "
Embrace challenges ☐ "
Ask for feedback ☐ "
Cri,cism is personal " ☐
Look smart " ☐
S,ck to what I know " ☐
Not afraid to fail ☐ "
Cri,cism is about capabili,es ☐ "
Failure means lack of talent " ☐
Ability
Inherent and sta:c Can grow
Growth vs. Fixed Mindset
41
“Are you sure you can do this, maybe I don’t have the talent.”
“What if I fail – I’ll be a failure.” “If I don’t try, I can protect
myself and keep my dignity.” “This would have been a snap if
I really had talent.” “It’s not my fault. It was
something or someone else’s fault.”
“I’m not sure I can do it now but I think I can learn to with time and effort.”
“Most successful people had failures along the way.”
“If I don’t try, I automatically fail. Where’s the dignity in that?”
“That is so wrong. Basketball wasn’t easy for Michael Jordan and science wasn’t easy for Thomas Edison. They had a passion and put in tons of effort.”
“If you don’t take responsibility, you can’t fix it. My advise is to listen – however painful it is – and learn whatever you can.”
What's driving this kind of behavior?
How can we promote?
Exercise
42 Timebox: 5 minutes
How can we change?
43
Establishing the Agile Mindset
What is Agile?
44
Agile is a MINDSET
Agile is a
MINDSET
Established through
4 VALUES
Guided by
12 PRINCIPLES
Manifested through many different
PRACTICES
Credit: Dr. Ahmed Sidky
45
Source: Guide to Agile Prac,ces. Agile Alliance,hRp://guide.agilealliance.org/subway.html
Frameworks/Practices
46
The Agile Mindset
Mindset
Values (4) Principles (12)
Frameworks Practices
Credit: Dr. Ahmed Sidky
(how we work?)
Scrum XP FDD DSDM
Daily meetings
Kanban Board
Definition of Done Three Questions
Iterations
Story Mapping
Retrospectives
User Stories
Burndown chart Backlog
Unit tests Acceptance tests
Definition of Ready
47
With your table group, discuss who will the key stakeholders and target audience to use the learning game
Exercise
WHO
• Key Stakeholders • Personas (Name / Goals)
OUTCOMES
48 Timebox: 10 minutes
As you were working together to identify the key stakeholders and personas:
" What went well? " What needs
improvement?
Inspect & Adapt
Timebox: 5 minutes 49
50
Developing Soft Skills
Processes and tools
Comprehensive documentation
Contract Negotiation
Following a plan
Individuals and interactions
Customer collaboration
Working software
Responding to change
over
over
over
over
Agile Values
51
Source: Daniel Goleman
Self Awareness
Self Management
Social Awareness
Relationship Management
Emot
iona
l Int
ellig
ence
Social Intelligence
Emotional awareness
Accurate self-assessment
Self-confidence
Self-Control
Trustworthiness
Ownership Adaptability
Innovation
Understanding others
Developing others Service Orientation
Leveraging diversity
Political awareness
Influence Communication
Leadership Conflict management
Change catalyst Building bonds
Collaboration Team abilities
Emotional Intelligence (EQ)
52
" Identify 5-10 soft skills that are most important to you
" Prioritize them from high to low
" Identify 2 action items to improve the identified skills
Exercise
53 Timebox: 3 minutes
Source: Peter Bregman. https://www.youtube.com/watch?v=CuPfbTAVBP4#t=15
Ownership Commitment
Trust
Morale
Responsibility
Community At
titu
de
Courage
Soft Skills
Servant Leadership Colla
bora
tion
54
Tony is one of your most talented developers. Most team members go to him for advise on technical issues. You are the leading the project and noticed that when it comes to meetings, he’s usually late. You brought it up to his attention a several times but this behavior continue to persist. It is hurting the team progress and affecting morale.
Exercise
55
• What are the different approaches we need to consider to rectify this issue? • Discuss with your table group.
Timebox: 3 minutes
56
Understanding communication barriers
Seek first to understand, then to be understood. – Stephen Covey
Communication barriers
" Identify the most common communication barriers in your organization
" What could you do to minimize them
57 Timebox: 3 minutes
58
Listening
Level 1: Ignoring
(Not really listening at
all)
Level 2: Pretending
(Yeah, uh-huh, right)
Level 3: Selective Listening
(Hearing only parts)
Level 4: Attentive Listening
(Focusing and paying attention to the words)
Source: The 7 habits of highly effective people by Stephen Covey
Level 5: Empathic Listening
(Understand the other person’s
paradigm and how they
feel)
We evaluate: we agree or
disagree
We probe: ask questions from our own
frame of reference
We advise: give counsel based on our experience
We interpret: try to figure people
out, explain their motives, based on our own paradigm
Barriers to Listening
Source: The 7 habits of highly effective people by Stephen Covey 59
" Pair up with someone and talk to them for 30 seconds about anything that comes to mind. (The person who is doing the listening should keep listening without interrupting)
" After 30 seconds, Switch roles
" Be prepared to report your observations to the whole group
Exercise
60 Timebox: 2 minutes
Effective Communication
Credit: Dr. Alistair Cockburn
61
62
Sharing Knowledge
• Knowl.edge : information,
understanding, or skill that you get from experience or education
: awareness of something : the state of being aware of something
Definition
Merriam-webster dictionary
63
Types of Knowledge
Explicit
Tacit
(Example: learning how to speak a language)
(Example: learning the rules of grammar)
Difficult to transfer to another person by means of wri,ng it down or verbalizing it
Knowledge that has been ar,culated, codified, and stored and can be readily transmiRed to others
90-95%
5-10%
Percentages are hypothetical
64
Explicit vs. Tacit
Explicit Tacit Documents Experience Data Thinking Information Competence Records Commitment
" What are the different characteristics of explicit vs. tacit knowledge? " Is Tacit knowledge transferrable? Why or why not?
65 Timebox: 3 minutes
Osmotic communication means that information flows into the background hearing of the team, so that they pick up relevant information as though by osmosis.
Osmotic Communication
Credit: Dr. Alistair Cockburn
66
" Pairing team members to enhance knowledge sharing
" Reduce errors and maintain consistency
" Promote learning
Pairing
67
68
Physical work environment
We shape our places and then our places shape us. -Winston Churchill
Physical setup
Image source: Motley fool
Environment can encourages or discourages certain team behaviors
69
70
Collaboration techniques
Alone we can do so little; together we can do so much. – Helen Keller
Collaborate: to work together especially in some literacy, artistic or scientific undertaking [1]; to work jointly with others or together especially in an intellectual endeavor. [2]
[1] Webster’s New World Dictionary of the American Language
[2] Merriam Webster Online Dictionary
Collaboration
Source: Jean Tabaka. Collabora,on Explained
71
Collaboration Culture
72
Source: Christopher Avery. The Responsibility Process
Owning your ability and power to create, choose and aRract
Doing what you have to instead of what
you want to
Laying blame onto oneself (oKen felt as
guilt)
Using excuses for things being the way
they are
Holding others at fault for causing
something
Giving up to avoid the pain of
Shame and Obliga,on
Giving up to avoid the pain of
Shame and Obliga,on
73
" Think of a high performing team you worked with or you would like to work with.
" What were the qualities that made it a high performing team?
" How did they collaborate?
Exercise
74 Timebox: 3 minutes
" What are the most important values to us as individuals and as a team?
" What do we need to do to succeed as a team?
" How do we want to resolve conflicts?
" How do we create a safe space for everyone?
Working Agreement
75
" If you were on a team, what would the working agreement look like?
" Write it down
Exercise
76 Timebox: 3 minutes
77
Techniques for shared
understanding The single biggest problem in communication is the illusion that it has taken place. - George Bernard Shaw
" Vision " SMART Goals " Information
Radiators " Regular touch
points
Shared Understanding
78
" Define a clear vision for the team.
" Reiterate vision often and communicate change in direction.
" Make it visible for everyone to see.
Vision
79
" Establish SMART goals (Specific, Measurable, Attainable, Realistic and Time bound)
" Review goals on a regular basis
" Make it visible for everyone to see
SMART Goals
80
" An Information Radiator is a display posted in a place where people can see it as they work or walk by.
" Radiators show information the team cares about without asking anyone a question.
" This means more communication with fewer interruptions.
Information Radiators
Source: Alistair Cockburn
81
" Is large and easily visible
" Is understood at a glance
" Is kept up to date
A good Information Radiator
82
Regular Touchpoints
Identify our goal for the day and agree on what will be done (serves as a daily planning meeting)
Raise any impediments and ensure someone will follow through to resolve them for the team
Image credit: Jason Yip
83
84
Shifts in Roles
Self-organizing teams aren’t characterized by a lack of leadership, but by a style of leadership. -Jim Highsmith
Agile Principles
" Agile Principle #5: Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. " Agile Principle #11: The best architecture, requirements, and designs emerge from self-organizing teams.
Source: agilemanifesto.org/principles.html
85
Daniel Pink in his book ‘Drive: the surprising truth about what motivates us’ explains that we are motivated by 3 simple things: – Autonomy (wanting to direct our
own lives) – Mastery (wanting to be good at
something) – Purpose (wanting to make a
difference)
What motivates us?
Source: youtube.com/watch?v=u6XAPnuFjJc
86
Self-organizing teams Creating a self-organizing team entails: " Getting the right people " Articulating the product vision, boundaries and team roles " Encouraging collaboration " Insisting on accountability " Fostering self-discipline " Steering rather than control
Source: Jim Highsmith
87
Roles Generalist Specialist Generalizing Specialist
Pro: Has one or more technical specialties (Java, Project Management, Business analysis)
Con: Lack of knowledge in a specific area may create an impediment
Pro: Has a deep knowledge in one domain area
Con: True specialists may create bottlenecks by focusing too much on their area and missing the bigger picture
Pro: has a dispersed knowledge over a wide array of areas
Con: May not be able to help the team in a specific area
Where does Agile teams fall? 88
" Think of how you would use agile in your current role
" Pair up with someone and discuss
Exercise
89 Timebox: 3 minutes
90
Value based work
Plan Driven Delivery
Requirements
Shall do this Will do that
Shall do this Will do that
Shall do this Will do that
Shall do this Will do that
Idea Resources Requirements
Everything is a PRIORITY
Schedule
How can we meet our “Initial Plan”?
Deliver
Scope
Budget Schedule
91
Value Driven Delivery
1 2 3 4 5 6 7 8
PRIORITIZED
Idea Resources Requirements Schedule Deliver
How can we deliver the highest value in the time we have?
Scope
Budget Schedule
1
3
4
2
5
6
7
8
92
Plan vs. Value driven delivery
Value
Time
Plan driven delivery
Value driven delivery
Time is up
There is value that can be delivered to the customer.
There is no value to be delivered to the customer.
93
M
Prioritization
S C W
Business V
alue
High
Low
To Do Doing Done
94
M
Prioritization
S C W
Business V
alue
High
Low
To Do Doing Done MUST HAVE
SHOULD HAVE
COULD HAVE
WON’T HAVE 95
When can we deliver
the product? �
Building a bit at a time “Incrementing” We build to finish
Build a rough version, validates it, bit at a time “Iterating” We build to learn
Throughout Where do we deliver
value faster? �
Where does the maximum
value happen? �
Source: Jeff Patton
Here
96
Incremental vs. Iterative
Slicing value
Vision Desired Outcomes
Product Backlog Feature 1
Feature 1 Feature 1
Feature 1 Feature 1
Feature 1 Feature 1
has to satisfy
who has
pay Goals and Needs
User Story 1
Iteration Backlog
User Story 4 User Story 5 User Story 6
User Story 3 User Story 2
to buy realized by
broken into
97
Slices of Value
98
Each slice of the product provides
that can be delivered to the customer
value
All we doing is looking at the time line, from the moment the customer gives us an order to the point when we collect the cash. And we are reducing the time line by reducing the non-value adding wastes. –Taiichi Ohno. Father of TPS
99
Receiving Value
Idea
Usage
Waste
In Manufacturing In Software In-‐Process Inventory Par,ally Done Work Extra Processing Extra Processes Overproduc,on Extra Features Transporta,on Handoffs Wai,ng Delays Mo,on Task Switching Defects Defects
Source: 7 wastes in soKware. Mary and Tom Poppendieck
100
101
Work in Progress (WIP)
Work in Progress (WIP)
Inventory Manufacturing
Software Ideas/Inputs Value
Is WIP good, Bad or Necessary?
102
‘Waste’ in Software Development
Waste Description Example Partially done work Work started but not complete % Code waiting for quality
assurance (QA) % Specs waiting for dev.
Extra processes Extra work that does not add value % Unused documentation % Unnecessary approvals
Extra features Features that are not required, or thought of as nice-to-haves
% Gold plating % Technology features
Task switching Multi-tasking between several different projects when there are context-switching penalties
% People on multiple projects
Waiting Delays waiting for reviews and approvals
% Waiting for document approvals
Motion The effort required to communicate or move information or deliverables from one group to another
% Distributed teams % Handoffs
Defects Defective documents or Software needs correction
% Requirements defects % Software bugs
Source: 7 wastes in soKware. Mary and Tom Poppendieck
103
Backlog Ready for Dev.
Development (5)
Tes:ng (3)
Accepted (2)
To be Deployed
In Done In Done In Done
Cycle time
Throughput
How long it takes a work item to go through the cycle?
How many work items are going through the cycle at a given ,me?
Limit WIP
Limiting WIP helps the team see the bottlenecks and “swarm” (collaborate) to alleviate it.
104
Why limit WIP?
105
The aim of WIP limits is
NOT to optimize resource utilization
But to optimize THROUHGPUT
106
Continuous Integration (CI)
" CI is a software development practice where members of a team integrate their work frequently (at least daily).
" Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible.
What is CI?
107 Source: Martin Fowler
" Discuss how this apply to your environment.
" Identify 3 ways to reduce integration issues on your projects.
" Write them down.
Why is CI important?
108 Timebox: 3 minutes
Scenario 1: Wait until the end
Team A
Team B
Team C
Code Integrate
109
Scenario 2: Integrate daily
Team A
Team B
Team C
Code Integrate
110
111
Continuous Delivery (CD)
" Release at anytime (on demand)
" Team can deploy to production throughout the cycle
" Automated tests are essential
112
Continuous Delivery
Deploy
Test
Build
" Interdependence between software development and IT Ops
" Close collaboration for everyone involved in the delivery process
DevOps (Development + Operations)
113
114
Defining the Customer
" Who are our stakeholders?
" What is their level of interest and influence?
" What are their personas? (Demographics and Psychographics)
Stakeholders
115
" Who is our target audience? (Demographics)
" Why would they buy our product? (Psychographics)
" What are their goals?
Personas
Name: Joe
Role: Student
Profile: Joe is a freshman in college who is curious about learning. He likes to spend time reading and share new articles with friends on social media.
Goals: - Learn online and share interesting information with his friends - Rate classes
116
117
User Involvement
1994 2011 2012 - 2013 User Involvement Executive management
support
Executive Management Support
Executive management support
User Involvement
Clear Statement of Requirements
Clear business objectives Optimization
Proper Planning Emotional maturity Skilled resources
Realistic Expectations Optimization Project management expertise
Smaller Project Milestones Agile process Agile Process
Competent Staff Project management expertise
Clear Business Objectives
Ownership Skilled resources Emotional Maturity
Clear Vision & Objectives Execution Execution
Hard-working, Focused staff Tools & Infrastructure Tools & Infrastructure
Source: Standish Group CHAOS Manifesto 2013
Success factors
118
Agile Principle #4
Business people and developers
must work together daily
throughout the project. 119
" Identify the right users (High interest/high influence)
" Establish a user group with a point of contact
" Build a team culture with a defined purpose
" Ask for their input/feedback
Increasing User Involvement
120
121
User Feedback
Feedback Loop Defined
A process has a feedback loop when the results of running the process are allowed to influence how the process itself works in the future.
122
123
When do we get feedback here?
" Where do you see the feedback loops in Agile practices?
" What are the benefits of shorter feedback loops vs. longer feedback loops?
Exercise
Timebox: 3 minutes 124
Feedback Loops
125
Customer
Are we there yet?
Need more work
Agile Principle #4: Business people and developers must work together daily throughout the project.
Team
Iteration Planning and throughout the iteration
Daily Standups
Iteration Reviews (The most feedback)
Evolving Product
When do we stop?
126 Credit: Jeff PaRon
Is the Product
good enough?
Do we have
budget?
No
Yes
STOP STOP
No
Yes Continue
When do we stop?
127
128
Planning
Planning is essential. Plans are useless. - Eisenhower
Misconceptions about Agile
129
" How much it will cost? " When will we be done? " What resources do we
need? " When can we release
our product?
Why do we plan?
130
Levels of Planning
Credit: Mike Cohn
What do we plan to do as a team to fulfill our iteration commitments? What is preventing us from getting there?
What slice of value will we deliver over the next 2-4 weeks?
Strategy
Product Vision
Product Roadmap
Release Plan
Iteration Plan
Daily Plan
What features will we deliver over the next 6-12 weeks?
What are we trying to accomplish by building this product?
How does this align with the overall organization goals?
What will be build when over the next 6-12 months?
131
During the product vision session, we address the following question:
" What are we trying to accomplish by building this product?
" What problem are we trying to solve?
Product Vision
132
" Understand ‘what we are trying to accomplish?’
" Define who the team members are and how they will work together
" Establish roles and responsibilities and level set the expectations
" Decide if the project is a ‘go’ or ‘no-go’
Project Charter
133
During the product roadmap session, we address the following questions:
" What gets build first? (Priorities)
" What are the desired outcomes?
Product Roadmap
134
During the release planning, we address the following questions:
" What features will be delivered in this release? (Priorities)
" What is our success criteria? (Outcomes)
" When can we release? (Timeline)
" What can prevent us from delivering? (Risk)
Release Plan
135
Iteration Plan
During the Iteration plan, we address the following questions:
" What stories will be delivered this iteration? (Priorities)
" What is our iteration goal? (Outcomes)
" What’s preventing us from reaching our goal?
" Is this getting us closer to our release? (Risk)
136
During the daily standup, we address the following questions:
" What is our goal for today? (Priority)
" What will we work on to reach the goal? (Outcomes)
" What’s in our way of achieving our goal or making making progress? (Risk)
Daily Plan
Timebox: 15 minutes
137
Traceability
Vision
Goal Goal
Feature Feature Feature
EPIC
Story
Story
EPIC
138
User Stories
As a <role>, I want to
<goal> so that I can
<benefit>
" User Stories has 3 main elements: & Card: written on an
index card as a placeholder for future…
& Conversation: exchange of thoughts, opinions and feelings
& Confirmation: what are the acceptance tests
139
Attributes of a User Story
Source: Bill Wake
INVEST
Independent (can be
scheduled and implemented in
any order)
Nego,able (capture the
essence not the details)
Valuable (needs to add value to the customer)
Independent (can be scheduled and implemented in
any order)
Es,matable (just enough es,mate
to help the customer rank and schedule)
Small (can be planned and fit
into an itera,on)
Testable (The story can be verified and tested)
140
Write user stories in the format of ‘As a <role>, I want to <goal> so that I can get <benefit>’ for the learning game
Exercise
WHAT
• User stories • Check the stories against the INVEST model
OUTCOMES
141 Timebox: 15 minutes
" Also called ‘Conditions of Satisfaction’ by Mike Cohn
" Are specific to a given product backlog item and define what must be true for that product backlog item to be considered done
" Example of Acceptance criteria: & User is logged in only when
proper credentials are provided
& User can request a password reminder
& User is locked out after three failed attempts
Acceptance Criteria
142
" Is an agreed upon set of things that must be true before any product backlog item is considered complete
" Example of Definition of Done: & The code is well written & The code is checked in & The code has been
inspected & The feature the code
implements has been documented as needed
Definition of Done
Source: Mike Cohn
143
144
Estimation
It’s better to be roughly right than precisely wrong John Maynard Keynes
" How much effort do we put into estimation to increase accuracy
" An estimate is just an estimate
Law of Diminishing Returns
145
Absolute vs. Relative Estimating
How tall is this building in feet?
How did you come up with the estimate?
Assume this building is 350 ft, what’s your estimate of the tall building?
146
" Estimate items (tasks or user stories) relative to other items rather than separately.
" Estimate size, derive duration.
Relative Estimating
Fibonacci sequence
147
Ideal time vs. elapsed time
Ideal time Elapsed time How long does an activity take without any interruptions?
How long does an activity take from start to finish?
Football game: 1 hour (4x 15 minutes quarters)
Football game: 4 hours (including commercials)
Source: Mike Cohn
148
" Velocity is a measure of a team’s rate of progress
" Velocity is a predictability measure NOT a productivity measure
Velocity
149
Estimate the stories you came up with during the story writing exercise
Exercise
WHAT
• Estimated stories in points using 0,1,2,3,5,8 OUTCOMES
150 Timebox: 10 minutes
151
Tracking and Reporting What’s measured improves. – Peter Drucker
" How are we doing? (Project, team and process health)
" What’s preventing us from making progress?
" What’s our planned vs. estimated pace? (velocity)
Agile Metrics
152
Burn Up charts
Burn Up charts give an indicator whether the team will deliver the functionality or need to add more iterations.
Stor
y po
ints
Iteration
Expected velocity: 10 points/iteration Iteration Expected Actual
0 0 0
1 10 10
2 20 19
3 30 20
4 40 35
5 50 50
6 60 58
7 70 63
8 80 63
9 90 78
10 100 90
11 110 100
12 120 105
Velocity
Forecasted
Addi:onal itera:ons: 2
153
Burn down charts shows the points remaining at the beginning of each iteration
Burn down charts
Expected velocity: 10 points / Iteration Iteration Expected Actual
0 120 120
1 110 120
2 100 110
3 90 100
4 80 97
5 70 95
6 60 80
7 50 70
8 40 62
9 30 45
10 20 37
11 10 25
12 0 20
Velocity
Addi:onal itera:ons: 2
Forecasted
154
" A cumulative flow diagram (CFD) shows the status of work in different queues (Analysis, Development, Testing, Deployment)
" It also shows if there is a bottleneck that needs to be addressed
Cumulative Flow Diagram
The widening area may be an indication of bottlenecks (work items are not being moved to the next queue
This area hasn’t changed and it may indicate a bottleneck with Dev tasks
155
Bug Tracking
Source: Scrumage.com
Bug tracking give team indicators such as: 1. Escaped defects (Bugs
that were not caught in testing)
2. How long does it take to fix bugs?
Most importantly, investigate why bugs are getting through and what can we do to catch them early in the process
156
Team Assessment Radar Chart
" A good tool for the team to assess their practices. " It is a participatory indicator on how the team are following their own practices. " This may be subjective
Itera:on
157
158
Process Adaptation
The illiterate of the 21st century will not be those who cannot read and write, but those who cannot learn, unlearn and relearn.
–Alvin Toffler
" A series of actions or steps taken in order to achieve a particular end.
" In our context, the Process is the way the project is delivered to build a product or service.
Process
What’s the problem with our processes today?
159
" Identify 3 ways on how we change our process today.
" Are these ways participatory or mandatory?
" Identify 2 approaches to make it participatory
Exercise
160
Inspect & Adapt
Agile Principle # 12: At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Image credit: growingagile.co.za
161
Adapting over Conforming
Jim Highsmith explains that: " Delivering great products requires exploration, not tracking against a plan.
" Have the courage to explore into the unknown and the humility to recognize mistakes and adapt to the situation.
162
When: At regular intervals (Usually at the end of each sprint)
Retrospectives
Who: The team
Why: Reflect on how to become more effective, then tune and adjusts its behavior accordingly
Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.
- Retrospective Prime Directive. Norm Kerth
163
Conducting a Retro
• Establish purpose/focus of the retrospective. • Share the plan for the meeting. Set the stage
• Create a shared pool of data (based on the focus/purpose). • Ground the retrospective in facts, not opinions. Gather data
• Observe patterns. • Build shared awareness. Generate insights
• Move from discussion to ACTION. • Focus on what the team can accomplish not what’s important
(1-2 actions)
Decide what to do
• Reiterate actions and follow up. • Appreciate contributions.
Close the retrospective
Source: Esther Derby
164
A Good Retrospective
" Discuss any personal, team or process issues openly.
" Discuss what worked and what needs to change.
" Agree on top action items to be addressed and fixed.
" Review these action items at the beginning of the next retrospective.
" Change it up (Innovation games). " Add the “Appreciation” game every
now and then.
165
How big is the system to develop?
How many lives lost if the system fails or how many billions of dollars lost?
How is the project remunerated for its effort?
How much of a stable architecture exist at the start of the project?
How is the team distributed? (Collocated, virtual, outsourced, etc.)
How long has the system been around? (evolu,on of legacy, maintenance)
How stable are the requirements and surrounding business environment?
What are the external rules imposed to the project to control its trajectory and how formal they are?
Source(s): SoftEd; Agility in context. Kruchten 2011.
Context Matters
166
167
Agile in context
" Think about a time where you had to learn a new skill (Pick one)
" Write down what it took to master it (The steps)
168
Exercise
Timebox: 3 minutes
Stages of Learning
SHU Follow the
Rule “Obey”
HA Break the
Rule “Detach”
RI Be the Rule
“Separate”
169
Stages of Learning SHU (Follow the Rule “Obey”)
170
Stages of Learning HA (Break the Rule “Detach”)
171
Stages of Learning RI (Be the Rule “Separate”)
172
173
Wrap-up/Questions
“The important thing is not to stop questioning. Curiosity has its own reason for existing.”
Albert Einstein
174
175
Recommended