overcoming some pitfalls of transitioning to agile
DESCRIPTION
I spoke to the Boston ASP.net User Group in April 2011 and this was the talk with the notes I addedTRANSCRIPT
Overcoming Some Pitfalls of Transitioning to Agile
Johanna RothmanNew: Manage Your Project Portfolio: Increase Your Capacity and Finish More
Projects@johannarothman
www.jrothman.com+1-781-641-4046
© 2011 Johanna Rothman
Quick Look at All Lifecycles
2
Copyright 2007 Johanna Rothman, from Manage it! Your Guide to Modern, Pragma3c Project management
© 2011 Johanna Rothman
You weren’t being successful enough
You gave the customers what they asked for, but not
what they wanted
Reacting to requirements changes was difficult
You wanted more predictability from your projects
Why Bother?
3
© 2011 Johanna Rothman
1. Interruptions
2. When will the project be done???
3. Overtime
4. Geographically distributed project
5. We need everything
6. Your product owner refuses to acknowledge technical debt or
defects
7. We have more than one product owner
External Pitfalls
4
© 2011 Johanna Rothman
Schedule Games
5
© 2011 Johanna Rothman
Managers must manage the project portfolio
Decide in advance what to do about previously released products and their support
Strategies:
Everyone on one team commits to just one project in an iteration. Do you need
multiple teams for multiple projects?
Sometimes you ask people to commit to a support team for one iteration
Shorten the iterations
Add cards to the backlog that say “support” as part of your estimates and what you
can commit to in an iteration
Manage the project portfolio
Eliminate Multitasking
6
© 2011 Johanna Rothman
Your management wants to know “When will the project
be done? Quick, we need to tell V-I-C”
Strategies
Explain that you will work in timeboxes, finishing work
until they don’t want to spend more money
Wideband Delphi for gross estimation for the backlog
Date for a date
Predicting an End Date with No Data
7
© 2011 Johanna Rothman
What happened to sustainable pace?
Strategies:
Shorten the timebox
Ask what success means for this project
Define project release criteria
Make sure you have a cross-functional team working towards release-able product
Make sure you have enough of the right people
Know what “done” means
Consider short timeboxes with overtime followed by a timebox with no overtime
Measure velocity
We Must Have Overtime
8
© 2011 Johanna Rothman
Distributed project without:
Cross-functional teams in each location who can work independently
Ranked requirements
Synchronized timeboxes (everyone’s timebox ends/starts at the same time)
Insufficient trust among project teams
Strategies:
Only accept cross-functional teams who can get to done in each location
Have a single product owner who ranks the product backlog and each team’s backlog
Synchronize the timeboxes
Get people together to build relationships and trust
A Hamstrung Geographically Distributed Project
9
© 2011 Johanna Rothman
What’s wrong with High/Medium/Low?
Strategies
Rank just enough for one iteration
Help the product owner rank the backlog before the next
iteration
Get a new product owner
Don’t work on the project until the requirements are ranked
The project team ranks the requirements
I Won’t Rank the Requirements
10
© 2011 Johanna Rothman
Product owner has trouble recognizing that technical debt or defects
need to be addressed with features
Strategies
Explain the cost of each feature without addressing technical debt
and with addressing technical debt
Create three backlogs for transparency: features, technical debt,
defects. Rank each then choose from each for each sprint
Don’t create more technical debt (Broken Window pattern)
Technical Debt Is Your Problem
11
© 2011 Johanna Rothman
You need product managers and they all want a say in what a team
does in one iteration
Strategies
Product owner meets with product managers in advance of the
iteration to negotiate ranking the product backlog
They choose one person to deal with the technical team
Always look for the most business value
We Have More Than One Product Owner
12
© 2011 Johanna Rothman
1.Someone wants to expand the timebox
2.Not integrating testing (or documentation or whatever)
inside the timebox
3.The project team doesn’t finish what they committed to
4.Changing requirements inside a timebox
5.Your standup meetings are sitdown-and-forever meetings
6.The team finishes stories very late in the iteration
Team-Created Pitfalls
13
© 2011 Johanna Rothman
Problems with timebox expansion
“Crossing the Desert” syndrome
No feedback about why they want to expand the timebox
You can’t measure velocity
Strategies:
Never extend a timebox while you are in it.
If the team’s estimates are a problem, reduce the timebox for the next iteration.
Loop until the team’s estimates are close.
Never allow other people to insert more items into the sprint’s backlog
Look for “overhead”, things that prevent people from working at full capacity
“Let’s Expand the Timebox”
14
© 2011 Johanna Rothman
“It works on my machine” or “The code compiles” or “The development is done” or
“I’m done”
Testing, documentation, whatever else is left out in the cold
Remember, the goal is release-able product
Strategies:
Work with the team to define: What does “done” mean? Make sure they understand
the product is supposed to be release-able
Integrate the testers and writers into the team
Don’t count anything that’s not done-done-done as part of the velocity
“Done” is Not Team-Based
15
© 2011 Johanna Rothman
The team doesn’t commit to the contents of an iteration
Strategies:
Make sure features (user stories) are on the backlog, not tasks
Reduce the size of each user story so it’s easier to estimate
Never allow any single person to commit to anything on behalf of the team
Ask the 3 questions at each standup (I use “what have you completed” as the first question)
Reduce the size of the timebox
Know what done means for each feature
Consider moving to TDD
Never allow a specialist to work alone on anything he or she knows
Fear of Commitment
16
© 2011 Johanna Rothman
A well-meaning person (sometimes a technical team member, sometimes a
Product Owner) has a great idea that he wants in this iteration. Your
customer will be devastated without this item in this iteration’s backlog.
Strategies:
Say No and reorder the entire product backlog if necessary
Consider stopping the iteration and restarting it
Shorten the iteration so people have more flexibility with the product
backlog
We Gotta Have It; We’re Toast Without It
17
© 2011 Johanna Rothman
Your standup meetings have problems:
Don’t occur at the same time every day
People sit down and the meeting takes longer than 15 minutes
No one makes a velocity chart at the meeting
People don’t complete items often
People use the meeting to solve problems
Strategies
Ask people to answer only these three questions. No other questions or answers in the meeting
What did I complete since the last standup?
What am I planning to do today?
What obstacles do you have?
At a retrospective, discuss your problems. Then define the problems so you can address them.
Our Standup Meetings Are Sit-Down-and-Forever
18
© 2011 Johanna Rothman
The team commits to too much
Implements by architecture
Stories are too large
Strategies
Implement by feature
Make stories smaller
Rethink estimation
Stories Complete Late in the Iteration
19
© 2011 Johanna Rothman
1.No one facilitates a retrospective to learn and adapt
2.The PM acts as Product Owner, Scrum Master, and line
manager
Other Common Pitfalls
20
© 2011 Johanna Rothman
Some people know about lessons learned meetings which can turn into a
blamefest. Why would you or the team want a retrospective?
Strategies:
Get a copy of Derby and Larsen’s Agile Retrospectives book and plan to
facilitate a two-hour end-of-iteration retrospective
Explain that agile is about “inspect and adapt” and that’s what the team
needs to do for the project so you can all make forward progress
Rotate retrospective facilitation among team members
We Don’t Need Retrospectives
21
© 2011 Johanna Rothman
I know some “Scrum Masters” who are also supposed to be line
managers, Product Owners, and run a support team in their spare
time.
Strategies:
Explain what each role is supposed to do
Choose one role. Remember, tactical work always wins
Take a look at: Functional Managers Acting as Scrum Masters: Not a
Good Idea
You Have Too Many Hats
22
© 2011 Johanna Rothman
Obstacles such as “overhead” are pitfalls
Listen for pitfalls:
We can’t do this because…
If we could just…
Once you’ve found them, address them!
Remember: inspect and adapt
Look for Obstacles
23
© 2011 Johanna Rothman
on http://www.jrothman.com
If you’d like me to stay in touch with you, please sign up
online or fill out a yellow form or give me a business card
Manage It!: Your Guide to Modern, Pragmatic Project
Management
Manage Your Project Portfolio: Increase Your Capacity and
Finish More Projects
There’s More...
24