Agile Project Management – SD Best Practices 2008
1
Presentation Copyright © 2008-2009, Agile For All, LLC. All rights reserved. Use by IACA permitted.
• Cell phones, pagers, PDA’s, etc. to silent
• If you have a question, please ask it. Don’t wait! It is better to answer the question while we are still in the same area than to go back.
• We will take a break after about 90 minutes
Before We Start
2Agile for Project Managers
Agile Project Management – SD Best Practices 2008
2
• 30+ years of software industry experience
• Scrum Alliance Certified Scrum Coach (CSC)
• Bachelor and Masters degrees in Computer Science
• Roles included Tester, Developer, Dev Manager, QA Manager, Product Manager, Project Manager, VP…
• Started with agile in 1999
Bob Hartman (Agile Bob)
303-766-0917
Blog at www.agilebob.com
4Agile for Project Managers
Agile Project Management – SD Best Practices 2008
3
Discussion:
• Please introduce yourself including:
– Name
– Company and Role
– Agile experience
5
Who are you?
Agile for Project Managers
Discussion:
• This workshop is to learn about agile, while participating in an agile project
• In other words, this workshop IS an agile project!
• What should the goal be?
• How about:
6
Our Goal
Agile for Project Managers
Agile Project Management – SD Best Practices 2008
4
• This is going to be just like an agile project• All of you represent certain roles
– Customer/Stakeholder– Team Members
• I represent certain roles– Product Champion– Team Member– Agile Project Manager
• We will go through an entire release, including planning, iterations, retrospectives, etc.
• Our iterations will each be 20-30 minutes in length, so we will be covering things VERY quickly!
How the Workshop Will Function
7Agile for Project Managers
• In an agile project you need two things to get started on a project:– Vision Statement
– Prioritized Product Backlog
• Our vision statement will be:FOR the attendees of this workshop WHO want to learn
more about agile software development THEworkshop IS AN agile project THAT will help them understand agile with real examples.
UNLIKE other workshops about agile OUR WORKSHOP will teach agile by being agile.
Starting the Project
8Agile for Project Managers
Agile Project Management – SD Best Practices 2008
5
Vision statement template
9
From “Crossing the Chasm” by Geoffrey Moore
Agile for Project Managers
Our product backlog (not prioritized!)
10
Release
Iteration Title VotesExpectations of Agile
Why Consider Agile?
Agile Metrics
Agile Process Basics
Agile Principles
Agile People and Roles
Agile PM vs. Traditional PM
Agile Planning
Agile Requirements
Agile Testing
Agile for Project Managers
Agile Project Management – SD Best Practices 2008
6
• Go from to
• Everyone that will work on the project should attend in order to have their input heard
• 1st part of meeting
• 2nd part of meeting ask questions
• Last part of meeting for initial planning– Non-core team members should use this
time to make sure their needs are addressed
Release planning meeting
11Agile for Project Managers
Discussion:
• What should our release backlog look like for this workshop?
12
Release planning
Agile for Project Managers
Agile Project Management – SD Best Practices 2008
7
• Purpose is to get ready to start coding iterations
• Gather people resources
• Get organized
• Identify early risks
Iteration 0
13Agile for Project Managers
• Some definitions:– Release – Final output of the development process
– Iteration – Small piece of the development time. Fixed length, usually 2 weeks, but can range from 1-4 weeks
– Backlog – list of work items for the product, release or iteration
• Our risk today is that we may run out of time– We will limit each section to no more than 25-30 minutes
– That should give us time for 4-6 iterations during the workshop
– We will re-evaluate after each iteration to make sure we get “the right 10 pounds of stuff in our 10 pound bag”
Workshop Iteration 0
14Agile for Project Managers
Agile Project Management – SD Best Practices 2008
8
• Team, Product Champion and Scrum Master– Purpose is for team to make commitment for what will be
done during the iteration
• 1st part: Ask questions and size stories.Make initial guess at commitment
• 2nd part: Break down storiesTeam does this withoutProduct Champion
• 3rd part: explain commitment(based on prior velocity)
Iteration planning meeting
15Agile for Project Managers
Agile Project Management – SD Best Practices 2008
9
Discussion:
• What are some ways to define agile software development?
18
What Do We Know
Agile for Project Managers
Agile Project Management – SD Best Practices 2008
10
Dilbert on agile
19
Dilbert knows agile!
Or, maybe not
Agile for Project Managers
Agile is…Building software in iterations
typically 1-4 weeksmost teams use 2 weeks
Teams work from a prioritized backlogprioritized by Product Ownerconsists of “user stories” of 1-3 days duration
Teams are self-organizing and self-directingagile project manager (Scrum Master) facilitates
meetings and removes impedimentsteams make commitments and work as a team
Every day starts with a daily stand-up3 questions answered by everyoneno one else allowed to participate
What others commonly say
20Agile for Project Managers
Agile Project Management – SD Best Practices 2008
11
Agile is…
building the highest value software…
with high quality…
as fast as possible.
A more purposeful definition
21Agile for Project Managers
1. Project is approved (generally outside agile)2. Release planning meeting3. Iteration 04. Iteration planning meeting5. Execute iteration (daily stand-up meetings)6. Iteration demo and retrospective7. If release not complete go to step 48. Release9. Release retrospective10.Repeat
Typical agile project flow
22Agile for Project Managers
Agile Project Management – SD Best Practices 2008
12
Agile process diagram
23Agile for Project Managers
Another agile process diagram
24Agile for Project Managers
Agile Project Management – SD Best Practices 2008
13
Agile Roles
25Agile for Project Managers
Iteration – the basic unit of agile
26
Iterations create a “product increment” of “potentially shippable
software.” This means everything is working. It DOES NOT mean we
can get it wrong in an iteration and then fix it all up in the next iteration!!!
Agile for Project Managers
Agile Project Management – SD Best Practices 2008
14
• Team and Scrum Master attend
– Others can attend but it is not necessary
– This is team time, others should not participate unless it is by agreement with the team
• 3 questions are answered by each person
– What did I do since we last met?
– What will I do before we meet again?
– What is blocking me?
Daily stand-up – Part I
27Agile for Project Managers
• Best is to add 3 more questions at the end of the meeting– Do anyone have any tasks that need to be added?
– Does anyone have anything we all need to know?
– Do any follow-up meetings need to be scheduled?
• NOTE: this part of the meeting is NOT a strict Scrum/Agile practice. It just seems to make things work better! People not on the team can participate here, especially during the 2nd
extra question.
Daily stand-up – Part II
28Agile for Project Managers
Agile Project Management – SD Best Practices 2008
15
• Everyone on the team participates in part I• No one outside the team participates in part I• In part II only items that are necessary for the
entire team to know are addressed
• THIS IS NOT A STATUS MEETING!!! This is a time for the team to interact– Hold each other accountable for results– Work better together by helping each other– Together make sure they are on track to meet the
iteration commitment
Things to remember
29Agile for Project Managers
• Everyone always follows the same rule for what to do next:– Go to the highest priority story and if you can do one
of the tasks, do that
– If you can’t do any of those tasks, find the highest priority story where you can do a task and do that
• Things are always being worked from the top of the list down, so highest value will be delivered as fast as possible
• These two things done together create “swarming” on stories
Assigning tasks – DON’T!
30Agile for Project Managers
Agile Project Management – SD Best Practices 2008
16
Usual method of assigning tasks
31
US1
US2
US3
Task 1 Task 2 Task 3
Task 1 Task 2 Task 3
Task 1 Task 2 Task 3
Bob
Jill
Don
Bob will do US1
Jill will do US2
Don will do US3
Agile for Project Managers
Usual method of assigning tasks
32
US1
US2
US3
Task 1 Task 2 Task 3
Task 1 Task 2 Task 3
Task 1 Task 2 Task 3
Bob
Jill
Don
Bob will do US1
Jill will do US2
Don will do US3
Bob
Jill
Don
Agile for Project Managers
Agile Project Management – SD Best Practices 2008
17
Stop here – Do we deliver value?
33
US1
US2
US3
Task 1 Task 2 Task 3
Task 1 Task 2 Task 3
Task 1 Task 2 Task 3
Bob
Jill
Don
Bob will do US1
Jill will do US2
Don will do US3
Bob
Jill
Don
Agile for Project Managers
Swarming example - start
34
US1
US2
US3
Task 1 Task 2 Task 3
Task 1 Task 2 Task 3
Task 1 Task 2 Task 3
Bob
Jill
Don
Agile for Project Managers
Agile Project Management – SD Best Practices 2008
18
Swarming example – 1st tasks
35
US1
US2
US3
Task 1 Task 2 Task 3
Task 1 Task 2 Task 3
Task 1 Task 2 Task 3
Bob
Jill
Don
Agile for Project Managers
Swarming example – 2nd tasks
36
US1
US2
US3
Task 1 Task 2 Task 3
Task 1 Task 2 Task 3
Task 1 Task 2 Task 3
Bob
Jill
Don
Bob
Jill
Don
Agile for Project Managers
Agile Project Management – SD Best Practices 2008
19
Stop here - Do we deliver value??
37
US1
US2
US3
Task 1 Task 2 Task 3
Task 1 Task 2 Task 3
Task 1 Task 2 Task 3
Bob
Jill
Don
Bob Jill
Don
Agile for Project Managers
Discussion:
• What did we learn?
• Any changes to the rest of the release plan?
38
Retrospective
Return
Agile for Project Managers
Agile Project Management – SD Best Practices 2008
20
Discussion:
• If someone asks you “Why agile?” how do you respond?
40
Why agile?
Agile for Project Managers
Agile Project Management – SD Best Practices 2008
21
• Business case essentials:
– Bottom line dollars and cents
– Improvements
• For this business case we should include:
– Business value created quickly
– Creating better products
– Team dynamics
– Planning improvements
Building a business case for agility
41Agile for Project Managers
• Stuffing envelopes can tell us a lot about agile
• What are the advantages of getting something released more quickly?
Adding Business Value Quickly – A Simple Example
42Agile for Project Managers
Agile Project Management – SD Best Practices 2008
22
Creating better products
43
Never Used45%
Rarely19%
Sometimes16%
Often13%
Always7%
Question: What percentage of software features are NEVER used?
Agile for Project Managers
Delivering business value quickly
44
Never or Rarely Used
64%
Sometimes16%
Often13%
Always7%
Question: If we get rid of the 64% of software that is rarely or never
used, what happens to our overall software development efforts?
Agile for Project Managers
Agile Project Management – SD Best Practices 2008
23
Discussion:
• When does the customer know what they really want in a product?
• How can we help them know earlier?
• Does that sound agile to anyone???
45
Expectations
Agile for Project Managers
• Morale improves– Team succeeds more often– Teams work together– Teams empowered to succeed
• Failures are very limited– A single iteration– Correction happens immediately– Team fails together so no blame– Happens quickly rather than
bleeding to death from a papercut
Changes to team dynamics
46Agile for Project Managers
Agile Project Management – SD Best Practices 2008
24
• Retrospections for correction and improvement
• Accurate management visibility
• Better predictability leading to success
Planning improvements
47Agile for Project Managers
Discussion:
• What other reasons exist for using agile?
48
Other Reasons
Agile for Project Managers
Agile Project Management – SD Best Practices 2008
25
Discussion:
• What did we learn?
• Any changes to the rest of the release plan?
49
Retrospective
Return
Agile for Project Managers
Agile Project Management – SD Best Practices 2008
26
• Based on lean manufacturing principles
• Often called Lean Software Development principles
• Form the backbone of all agile practices
• Ignore at your own risk!
Agile Principles
51Agile for Project Managers
• Unwavering guides• Always good• Foundational• Never change
“Principles are underlying truths that don’t change over time or space...” Tom and Mary Poppendieck, “Implementing Lean Software Development – From Concept to Cash”
What are principles?
52Agile for Project Managers
Agile Project Management – SD Best Practices 2008
27
• Things we do• Fit the situation• Apply principles• Change as needed
“… while practices are the application of principles to a particular situation.” Tom and Mary Poppendieck, “Implementing Lean Software Development – From Concept to Cash”
What are practices?
53Agile for Project Managers
This sums it up best
“Principles are underlying truths that don’t change over time or space, while practices are the application of principles to a particular situation.
Practices can and should differ as you move from one environment to the next, and they also change as a situation evolves.”
(entire quote from Tom and Mary Poppendieck’s book “Implementing Lean Software Development: From Concept to Cash”)
This section talks about PRINCIPLES
54Agile for Project Managers
Agile Project Management – SD Best Practices 2008
28
• Eliminate waste
• Build Quality In
• Deliver Fast
• Improve the System
• Defer Commitment
• Respect People
• Create Knowledge
Agile Principles in a Nutshell
55Agile for Project Managers
• Following these principles avoids many of the errors that plague the software industry today
Why these particular principles?
56Agile for Project Managers
Agile Project Management – SD Best Practices 2008
29
Boiling it down to a single thought
57Agile for Project Managers
Even better is…
58
This is at the heart of continuous
improvement – the heart of agile.
This is the “one big thing” to remember.
Agile for Project Managers
Agile Project Management – SD Best Practices 2008
30
• Building in iterations
• Daily stand-up
• Automated testing
• Nightly build
• Iteration planning
• Product Champion (Product Owner)
• Release planning
• Retrospectives
Agile Practices vs. Principles
59Agile for Project Managers
Discussion:
• What did we learn?
• Any changes to the rest of the release plan?
60
Retrospective
Return
Agile for Project Managers
Agile Project Management – SD Best Practices 2008
31
Dilbert
62Agile for Project Managers
Agile Project Management – SD Best Practices 2008
32
Discussion:
• Are agile requirements different? If so, how are they different?
63
Agile Requirements
Agile for Project Managers
The prioritized backlog(s)
64
Product backlog
All possible features
in priority order
Release backlog
List of features for
a given release
Iteration backlog
List of STORIES
for an iteration
Agile for Project Managers
Agile Project Management – SD Best Practices 2008
33
Making things “agile ready”
65
EPIC/FEATURE(EPIC:Reporting System)
Minimally
Releasable Feature
(MRF:Canned Reports)
Minimally Releasable
Feature
(MRF:Template Reports)
Minimally
Releasable Feature
(MRF:Direct Queries)
User
Story
User
Story
User
Story
User
Story
User
Story
Tasks Tasks Tasks
Notice the elimination of
waste (agile principle) by
not spending time on
pieces that aren’t needed
for the release/iteration.
Product Champion
creates these items
Product Champion and
dev team create these
items
Team
creates
these
Agile for Project Managers
User Story Template
66Agile for Project Managers
Agile Project Management – SD Best Practices 2008
34
Another way to look at it
67Agile for Project Managers
Some rules for the backlog
68Agile for Project Managers
Agile Project Management – SD Best Practices 2008
35
Guidelines
69
15% of backlog is iteration ready as user stories
25% of backlog is in the form of minimally
releasable features
The rest of the backlog is still in the form of
epics or high level features
DO NOT BE OVERLY PRECISE ABOUT THIS!!! These are
just guidelines. Do whatever works best for the team.
Agile for Project Managers
Discussion:
• What did we learn?
• Any changes to the rest of the release plan?
70
Retrospective
Return
Agile for Project Managers
Agile Project Management – SD Best Practices 2008
36
Discussion:
• How do we do testing today?
• How is that working for us?
72
Testing
Agile for Project Managers
Agile Project Management – SD Best Practices 2008
37
• Gold standard for agile is that each iteration creates potentially shippable code, which means– All unit tests pass
– All acceptance tests pass
• To meet this standard means that testing needs to be done DURING the iteration, not after– Tests must be written before or concurrently with
developing the software
What does “done” mean?
73Agile for Project Managers
Defining the types of testing
74
Acceptance Tests
Business Intent(Design of the Product)
UsabilityTesting
ExploratoryTesting
Unit Tests
Developer Intent(Design of the Code)
PropertyTesting
Response,Security
Scaling,…
from Brian Marick
Technology Facing
Business Facing
Sup
po
rt P
rogr
amm
ing
Cri
tiq
ue
Pro
du
ct
Automated(QA)
Manual(Anyone)
Automated(Developer)
Tool-Based(Expensive)
Agile for Project Managers
Agile Project Management – SD Best Practices 2008
38
• Product Champion refines stories and acceptance tests from Release Planning meeting, a few days before the Iteration Planning meeting
• Developers/Testers add more detailed tests in the Iteration Planning meeting
• Developers/Testers continue to build out in the Iteration – failing tests until code is implemented
• Developers get tests to pass
• Becomes part of the Regression test suite when story is accepted
Timeline for Acceptance Tests
75Agile for Project Managers
Build quality in (agile principle) in action
76
C
o
s
t
Time
Cost to fix defects based on when they are found
Finding and fixing defects as soon as they are created is much
cheaper than finding and fixing them further along in the process.
Agile for Project Managers
Agile Project Management – SD Best Practices 2008
39
• We have to validate
– That we understand what is needed
– That we did what we wanted
– That the product is of sufficient quality
• We must push testing up early
– Tests improve the conversation between customers and developers
– Tests become executable specifications
Validation and testing
77Agile for Project Managers
Remember…
78Agile for Project Managers
Agile Project Management – SD Best Practices 2008
40
• FIT: Framework for Integration Tests (html)
• FitNesse (wiki)
Open source tools for automated testing
fit.c2.com/
www.fitnesse.org/
79Agile for Project Managers
Discussion:
• What did we learn?
• Any changes to the rest of the release plan?
80
Retrospective
Return
Agile for Project Managers
Agile Project Management – SD Best Practices 2008
41
Measure appropriately
82
DILBERT: © Scott Adams/Dist. by United Feature Syndicate, Inc.
Remember, be careful what you measure!!!
Agile for Project Managers
Agile Project Management – SD Best Practices 2008
42
• Need to know only a few things:– What items have been completed and what items are
not completed
– How are we doing in relation to our plan for the iteration
• Do not want to track metrics that will create waste– Processing raw data into status reports
– Generating reports that aren’t useful• Remember, you get what you measure (Dilbert comic)
Metrics During Iterations
83Agile for Project Managers
Iteration status board
84
User Story
User Story
User Story
Task
Task
Task
Task
Task
Task
Task
Committed In Process Completed
Task
Task
Agile for Project Managers
Agile Project Management – SD Best Practices 2008
43
Burn-down chart
85
0
10
20
30
40
50
60
70
1 2 3 4 5 6 7 8 9 10
S
t
o
r
y
P
o
i
n
t
s
Day
Burn-down Chart
Remaining
Agile for Project Managers
Burn-up chart
86
0
10
20
30
40
50
60
70
1 2 3 4 5 6 7 8 9 10
S
t
o
r
y
P
o
i
n
t
s
Day
Burn-up Chart
Committed
Completed
NOTE: This shows a very bad practice. A team should NEVER
drop scope from an iteration!
Agile for Project Managers
Agile Project Management – SD Best Practices 2008
44
• Burn-up/burn-down charts at the release level
• Impediment list (and results)
• Retrospective action items, owners and results
Additional artifacts prior to release
87Agile for Project Managers
• We often need to measure the performance of people
Performance Related Metrics
88Agile for Project Managers
Agile Project Management – SD Best Practices 2008
45
Measure UP
89
Span of
control (dev)
– items
directly
controlled
Span of influence –
must have teamwork
and rely on others to
succeed
Span of control (dev): Coded story points
Span of control (QA): Number of tests run
Span of influence: Features in the field
with no reported bugs in 90 days
Span of
control (QA)
– items
directly
controlled
Agile for Project Managers
Discussion:
• What other metrics could you use that make sense in an agile environment?
90
Metrics
Agile for Project Managers
Agile Project Management – SD Best Practices 2008
46
Discussion:
• What did we learn?
• Any changes to the rest of the release plan?
91
Retrospective
Return
Agile for Project Managers
Agile Project Management – SD Best Practices 2008
47
Agile (Scrum) roles
93
Users/Stakeholders
•Those that are going to
use the product or have
a vested interest in how
it turns out
Team
•The team that will create
the product
•Includes EVERYONE
that is part of product
creation
Agile Project Manager
(Scrum Master)
•Facilitates of meetings
•Removes impediments
•Runs interference for
the team (firewall for
team)
Product Champion
(Product Owner)
•Owner of the backlog
(prioritizes and makes
decisions)
•Represents users and
stakeholders when talking
to team
•Represents team when
talking to users and
stakeholders
Agile for Project Managers
• Scrum Teams are filled with people who have skills, not people playing roles
• The individuals on a team self-organize for the task at hand
• The basic unit is the “Teamlet” or “Work Cell”– The Teamlet has all the skills it needs (analysis,
development, design, test, documentation, …)
– It typically consists of 2-4 people to get all the skills “covered”
– It swarms on one thing at a time
Self-Organizing Team
94Agile for Project Managers
Agile Project Management – SD Best Practices 2008
48
• One Bite at a Time– Do things a little at a time, with planning, validation, and management
of the pieces.
• Validation Centricity– The activities of validation, verification and test are “more important”
than those of analysis, design, and construction; and that we must actively look for things that cause us to change.
• Avoid and Eliminate Waste– Work on those things with the most value; have retrospectives to
evaluate process, etc
• Risk Awareness– Base decisions on risk analysis and mitigation – requirements risk,
architectural risk, technical risk, quality risk, people risk, etc
• Let Business Value Lead– Decisions must be based on the product, not documented plans,
analyses, requirements, or designs. The process doesn’t lead.
“Good” Team Philosophies, Found in Agile
95Agile for Project Managers
• There are also personal qualities we like to see in the members of our team. We call them the “team values”
– Play To Win
– Communication
– Cooperation
– Trust
Personal Qualities We Want
96Agile for Project Managers
Agile Project Management – SD Best Practices 2008
49
• Many people play "not to lose"
• Playing to win beats playing "not to lose" almost every time
• Symptoms of playing "not to lose"– Lots of paper
– Lots of meetings
– "by the book" development
– It's CYA time…
• Playing "not to lose" usually creates waste
Play to Win
97Agile for Project Managers
• Communication is perhaps the most important aspect of software development
• Used for
– Planning
– Laying out scope
– Getting feedback
– Explaining paths taken
Why We Communicate
98Agile for Project Managers
Agile Project Management – SD Best Practices 2008
50
• We are a team – a group of individuals that work together to be better than any of its parts
• Communication between members of the team is absolutely essential
• But even more important are– Cooperation – the willingness to subvert ones own
interests to those of the team, and work together to achieve them
– Trust – knowing that other members of your team are doing the best they can to do what is good for the team
• No individual blame – the process allowed it, so improve the process!
Cooperate and Trust
99Agile for Project Managers
• Removes barriers to help team become more efficient and productive
• Facilitates close cooperation and creativity across all roles and functions
• Helps team remain focused on doing the most important things
• Can play role of process coach or help the team evolve their process
• Keeps Daily Scrum/Standup on task and on track• Helps resolve the impediment issues list, provides
status
Agile Project Manager (Scrum Master)
100Agile for Project Managers
Agile Project Management – SD Best Practices 2008
51
Product Champion
101
Represents (is a champion for) anyone
that is not present during interactions that
occur throughout the process
Needs to…
Empathize with customers
Understand the technology
Know when to listen!
Agile for Project Managers
• Agile development is not obvious:– It relies on its people– It takes extraordinary discipline
• Your individuals must have personal values that support agility– Developers– Managers– Customers
• These values are crucial– Without them you have no chance with any process– With them you can make almost any process work
Remember, values are key
102Agile for Project Managers
Agile Project Management – SD Best Practices 2008
52
Discussion:
• What did we learn?
• Any changes to the rest of the release plan?
103
Retrospective
Return
Agile for Project Managers
Agile Project Management – SD Best Practices 2008
53
• You will release more software faster– You will release the highest value software as quickly as possible– More code will NOT be written in less time, but when you are
continuously releasing high value software it APPEARS that you are going faster
• Agile doesn’t need any documentation– The phrase to keep in mind is “just enough, just in time” and
this applies to most agile myths
• The developers run the show in agile– The developers follow the rule of finding the highest priority
task to work on and doing that– The Product Champion role defines the priorities, not the
development team
Common myths about agile
105Agile for Project Managers
• The team will have a lot of questions– Questions should generally be funneled through a small
number of people
– This is where it is very useful to have a coach!• The worst thing to do is to try and make up an answer on the fly
• Even if you are “somewhat sure”, use your coach
• The team will want to know how/when they will be getting started with what they learned– This needs to be communicated clearly
– There will be some questions about how other groups are going to be integrated – again, communicate clearly
Immediate expectations
106Agile for Project Managers
Agile Project Management – SD Best Practices 2008
54
• Planning will be completely different– People will be uncomfortable with new methods– Stick with it, this stuff really does work!
• There will be some confusion– This is entirely normal!– Work through it and improve your understanding of
the process– Again, get your coach involved if there are significant
issues
• Don’t trust the results of this first iteration!– It is the first time people are doing this and it will
almost certainly be wrong
Iteration 1
107Agile for Project Managers
• The bad news: results may not be what you expect– Iteration 1
• Team will likely only achieve 65% of what they believe they will achieve
• Plan on this and only allow the team to commit to about 65% of what they think they will be able to complete
– Iteration 2• Percentage of achievement is likely to be 80% of what the team believes
they can complete
– Iteration 3• Percentage increases to approximately 90%
– All of these iterations• Warts in the current system and assumptions will be exposed
• There is no place to hide the elephant in the room!
• The good news: things will continue to improve!
Iterations 1-3
108Agile for Project Managers
Agile Project Management – SD Best Practices 2008
55
• After the 3rd iteration the team should be able to have an accurate assessment of how much work they can do in each iteration
• It is important to use “yesterday’s weather” when deciding how much work can be done in an iteration
• Teams will generate the same amount of software as they did previously, but…– The software they are creating will be more in line with
expectations... assuming they are following what they learned
– The software should be of higher quality if developers and testers work together in an agile way
After iteration 3
109Agile for Project Managers
• It is common for the process to degrade over time– We don’t really need to do that part…– It takes too long to do that…– Why do we want to keep doing that…
• DO NOT LET THIS HAPPEN!– The process should be improved, but that does not
mean removing essential pieces – that is NOT improvement
– If there is a temptation to remove pieces of the process, examine the agile principles and determine how else to solve the same problem
Long-term
110Agile for Project Managers
Agile Project Management – SD Best Practices 2008
56
• What teams generally experience– Anywhere from 25-50% improvement in productivity
• Some teams see as much as 300% improvement!• But be careful how this is measured
– Often teams are producing the same amount of software in terms of lines of code generated
– The features they are adding are the right features at the right time, which means… overall to get a release they generally need to create fewer features
– Higher morale• They are succeeding and responding to change
• What organizations generally experience– Software is created more quickly because… fewer
features need to be created to satisfy the customer
Potential results
111Agile for Project Managers
What others are seeing
112Agile for Project Managers
Agile Project Management – SD Best Practices 2008
57
VersionOne Survey Results (2008)
113
Improvement Noted >10% improvement >=25% improvement
Increased productivity 89% 56%
Reduced software defects 84% 56%
Accelerated time-to-market 83% 54%
Reduced cost 65% 30%
Survey asked people: Please try to estimate SPECIFIC IMPROVEMENTS
you have actually realized from implementing Agile practices.
Source: VersionOne 2008 State of Agile Development Survey
NOTE: All 2008 data is within 2% of 2007 data implying these numbers are not
one-time anomalies
Biggest causes of company-wide agile failure:
Company philosophy or culture could not be overcome – 23%
Lack of experience with agile – 21%
Agile for Project Managers
Agile is a Proven ApproachSome Agile Companies (there are MANY more)
114Agile for Project Managers
Agile Project Management – SD Best Practices 2008
58
Discussion:
• What did we learn?
• Any changes to the rest of the release plan?
115
Retrospective
Return
Agile for Project Managers
Agile Project Management – SD Best Practices 2008
59
• In preparing for battle I have always found that plans are useless, but planning is indispensable,”
– Dwight D. Eisenhower
Multi-Level Planning in Agile
ProductBacklog
ReleaseBacklog
IterationBacklog
Release Planning Iteration Planning
117Agile for Project Managers
• Exist at 3 levels:– Product backlog – everything that might go into the
product
– Release backlog – everything that is currently committed for a release of the product
– Iteration backlog – everything that is committed for the current release
• The Product Champion OWNS the backlogs!!!
• Each backlog is kept in priority order at all times based upon the best information currently available
The Prioritized Backlogs
118Agile for Project Managers
Agile Project Management – SD Best Practices 2008
60
• Agile is all about adapting to change, and without constant reprioritization it is impossible to adapt
• Does it make sense to develop iteratively, learn something, then not reprioritize based on what was learned?
• Let’s look at a simple example of this in practice…
Why Prioritization is Important
119Agile for Project Managers
Starting Feature List (non-agile)
120
Feature 1
Feature 2
Feature 3
Feature 4
Feature 5
Feature 6
To be implemented Completed
Agile for Project Managers
Agile Project Management – SD Best Practices 2008
61
At Project Completion
121
Feature 2
Feature 5
Feature 1
Feature 3
Feature 4
Feature 6
To be implemented Completed
Agile for Project Managers
At Project Completion
122
Feature 1
Feature 2
Feature 3
Feature 4
Feature 5
Feature 6
To be implemented Completed
Agile for Project Managers
Agile Project Management – SD Best Practices 2008
62
What Was Actually Desired
123
Feature 1
Feature 2
Feature 3
Feature 4
Feature 5
Feature 6
To be implemented Completed
Agile for Project Managers
What Was Actually Desired
124
Feature 1
Feature 2
Feature 3
Feature 4
Feature 5
Feature 6
To be implemented Completed
Feature 7
Agile for Project Managers
Agile Project Management – SD Best Practices 2008
63
Why Reprioritization is Important (start list -agile)
125
Feature 1
Feature 2
Feature 3
Feature 4
Feature 5
Feature 6
To be implemented Completed
Agile for Project Managers
1st Iteration
126
Feature 1
Feature 2
Feature 3
Feature 4
Feature 5
Feature 6
To be implemented Completed
Agile for Project Managers
Agile Project Management – SD Best Practices 2008
64
Reprioritize After Iteration
127
Feature 1
Feature 2
Feature 3
Feature 4
Feature 5
Feature 6
To be implemented Completed
Agile for Project Managers
2nd Iteration
128
Feature 1
Feature 2
Feature 3
Feature 4
Feature 5
Feature 6
To be implemented Completed
Agile for Project Managers
Agile Project Management – SD Best Practices 2008
65
Reprioritize After Iteration
129
Feature 1
Feature 4
Feature 2
Feature 3
Feature 5
Feature 6
To be implemented Completed
Agile for Project Managers
3rd Iteration
130
Feature 1
Feature 2
Feature 3
Feature 4
Feature 5
To be implemented Completed
Feature 6
Feature 7
Agile for Project Managers
Agile Project Management – SD Best Practices 2008
66
3rd Iteration
131
Feature 1
Feature 2
Feature 3
Feature 4
Feature 5
To be implemented Completed
Feature 6
Feature 7
Agile for Project Managers
Discussion:
• How can we properly prioritize our backlog?
132
Prioritizing
Agile for Project Managers
Agile Project Management – SD Best Practices 2008
67
The bottom line on prioritization
133Agile for Project Managers
• Customer value (what is it worth to customers)
• Internal value (non-functional items)
• Business risk (how bad is it if we don’t do it)
• Technical risk (if we do it how risky is it)
• Business advantage (what can we gain from it)
Components of business value
134Agile for Project Managers
Agile Project Management – SD Best Practices 2008
68
• Other pieces can be added to the basic components of business value
• Somehow they have to be correlated in a way that allows ranking by business value
• Any ideas???
It is still a black art
135Agile for Project Managers
Sometimes simple works well
136
Business Value Calculation
Story Customer Internal Biz risk Tech risk Biz Adv Biz Value
Reporting system 60 10 2 1 3 420
Admin section 40 30 3 3 1 490
Startup wizard 90 0 4 1 2 630
Server O/S upgrade 10 90 2 4 1 700
(Customer value + Internal Value) x (Biz Risk + Tech Risk + Biz Adv)
BUT… don’t rely just on numbers. Use your brain and make good
business decisions based on what you know. Numbers only guide.
Agile for Project Managers
Agile Project Management – SD Best Practices 2008
69
An important point
137Agile for Project Managers
Discussion:
• When are we done?
• Feature driven, date driven, or something else?
138
Planning
Agile for Project Managers
Agile Project Management – SD Best Practices 2008
70
Discussion:
• What did we learn?
• Any changes to the rest of the release plan?
139
Retrospective
Return
Agile for Project Managers
Agile Project Management – SD Best Practices 2008
71
Discussion:
• What do traditional project managers do?
141
Being a PM
Agile for Project Managers
• Based on command and control
• Heavy on planning
– Gantt and Pert chart centric
• Directs the work of the team to match the plan
• Stereotype is a person that drives the team
Traditional project manager
142Agile for Project Managers
Agile Project Management – SD Best Practices 2008
72
• Supports the team rather than driving the team
• Removes impediments for the team
• Represents the team to those outside the team
• Lets the team solve their own problems
– Coaches the team and helps them improve
Agile project manager
143Agile for Project Managers
• In Scrum this role is called Scrum Master• This role facilitates all meetings
– Release planning– Iteration planning– Daily stand-ups– Retrospectives
• Responsible for removing impediments– Responsible for does not imply they have to do the work to remove the
impediment!– This is a BIG piece of the role
• Very short timeframes in agile• Short delays removing impediments have drastic effects
• Supports the team by helping however necessary– Communicates on behalf of the team to allow them to focus– Keeps the team true to the agile process– Makes sure the team keeps grinding away and making progress
• Tracks and reports status
More specifically…
144Agile for Project Managers
Agile Project Management – SD Best Practices 2008
73
• Rather than plan, instruct and direct, the agile project manager facilitates, coaches and leads.
- scrumalliance.org• One who uses the Scrum framework, by focusing on
facilitation, leadership, report building and communication in place of prescribed command as process control.
- wiki.answers.com• Unlike traditional project manager roles, the ScrumMaster
does not assign individual tasks to the developers or QA but rather the development team self-organizes on each iteration and determines who will do each task.
- Hector Correa in CoDe Magazine
What others say
145Agile for Project Managers
• Making spaghetti can teach us a lot about why directing is harder than letting the team solve problems on their own.
Demonstration
146Agile for Project Managers
Agile Project Management – SD Best Practices 2008
74
Discussion:
• What did we learn?
• Any changes to the rest of the release plan?
147
Retrospective
Return
Agile for Project Managers
Agile Project Management – SD Best Practices 2008
75
• Coding is finished, now time for release related activities which may include…– Final verification testing
– Property tests not done during the iterations (due to cost or complexity). Things like security testing, compliance testing, response time testing, scalability testing, etc.
– Complete documentation
– Complete training
– Complete rollout to production servers
• Celebrate!
Normal Agile Release
149Agile for Project Managers
• Any quick questions on what we covered?
• What did we not cover that we could cover very quickly right now?
Workshop Release: Tie Up Loose Ends
150Agile for Project Managers
Agile Project Management – SD Best Practices 2008
76
• Anyone can attend– Team members are REQUIRED!
• Start with 5 easy questions1. What did we do well?
2. What did we do less well?
3. How did we improve?
4. What actions can we take to address things we did less well (and who will own them)?
5. What can we do to improve next iteration (and who will own these items?
Retrospectives
152Agile for Project Managers
Agile Project Management – SD Best Practices 2008
77
• Create a document or wiki page with the results of every retrospective– Create knowledge (agile principle) to help others
• “How did we improve?” question should at least address action items from previous iteration
• Hold people accountable for items they own, BUT DON’T BLAME PEOPLE!– The process allowed it to happen– Change the process so it doesn’t happen again
• This is a primary way for the team to improve so use it as effectively as possible
Remember
153Agile for Project Managers
• Address a recurring problem– If the same problem keeps coming up, use the 5 why’s
to get to the root cause
• Ask additional questions– What would we change if we were in charge?
• Interestingly, the team is more in charge than they believe and many of these items can be implemented
– What types of feedback have been most useful?
– What one question would we like users to answer?
– What risks do we need to identify right now?
• Think outside the box – don’t limit the team!
Going further
154Agile for Project Managers
Agile Project Management – SD Best Practices 2008
78
Discussion:
• How did this format work?
– What went well, what didn’t go so well?
• Did we get “the right 10 pounds of stuff in our 10 pound bag?”
• What should I change for next time?
155
Our Retrospective
Agile for Project Managers
Agile Project Management – SD Best Practices 2008
79