I spoke to the Boston ASP.net User Group in April 2011 and this was the talk with the notes I added

1. Overcoming Some Pitfalls of
Transitioning to Agile
Johanna Rothman
New: Manage Your Project Portfolio: Increase Your Capacity and Finish More
Projects
@johannarothman
www.jrothman.com
+1-781-641-4046

2. Quick Look at All Lifecycles
Copyright
2007
Johanna
Rothman,
from
Manage
it!
Your
Guide
to
Modern,
Pragma3c
Project
management
2 © 2011 Johanna Rothman

3. Why Bother?
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
3 © 2011 Johanna Rothman

4. External Pitfalls
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
4 © 2011 Johanna Rothman

5. Schedule Games
5 © 2011 Johanna Rothman

6. Eliminate Multitasking
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
6 © 2011 Johanna Rothman

7. Predicting an End Date with No Data
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
7 © 2011 Johanna Rothman

8. We Must Have Overtime
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
8 © 2011 Johanna Rothman

9. A Hamstrung Geographically
Distributed Project
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
9 © 2011 Johanna Rothman

10. I Won’t Rank the Requirements
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
10 © 2011 Johanna Rothman

11. Technical Debt Is Your Problem
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)
11 © 2011 Johanna Rothman

12. We Have More Than One Product
Owner
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
12 © 2011 Johanna Rothman

13. Team-Created Pitfalls
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
13 © 2011 Johanna Rothman

14. “Let’s Expand the Timebox”
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
14 © 2011 Johanna Rothman

15. “Done” is Not Team-Based
“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
15 © 2011 Johanna Rothman

16. Fear of Commitment
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
16 © 2011 Johanna Rothman

17. We Gotta Have It;
We’re Toast Without It
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
17 © 2011 Johanna Rothman

18. Our Standup Meetings Are
Sit-Down-and-Forever
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.
18 © 2011 Johanna Rothman

19. Stories Complete Late in the
Iteration
The team commits to too much
Implements by architecture
Stories are too large
Strategies
Implement by feature
Make stories smaller
Rethink estimation
19 © 2011 Johanna Rothman

20. Other Common Pitfalls
1. No one facilitates a retrospective to learn and adapt
2. The PM acts as Product Owner, Scrum Master, and line
manager
20 © 2011 Johanna Rothman

21. We Don’t Need Retrospectives
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
21 © 2011 Johanna Rothman

22. You Have Too Many Hats
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
22 © 2011 Johanna Rothman

23. Look for Obstacles
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
23 © 2011 Johanna Rothman

24. There’s More...
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
24 © 2011 Johanna Rothman