Overcoming Some Pitfalls of Transitioning to Agile

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

http://www.jrothman.com


© 2011 Johanna Rothman

Quick Look at All Lifecycles

2

Copyright 2007 Johanna Rothman, from Manage it! Your Guide to Modern, Pragma3c Project management


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


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


Schedule Games

5


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


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


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


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


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


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


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


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


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


“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


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


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


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


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


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


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


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

http://jrothman.com/blog/mpd/2010/06/functional-managers-acting-as-scrum-masters-not-a-good-idea.html





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


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



http://www.jrothman.com/pragmaticmanager

http://www.jrothman.com/pragmaticmanager

Overcoming Some Pitfalls of Transitioning to Agile

Business

Transcript of Overcoming Some Pitfalls of Transitioning to Agile