Resource HuggingJuly 2013

About me

Paul RobbinsAPI Product Manager

About Knewton

Education Technology start-upFocus on personalized learning by utilizing big data and machine learning

Scope Creep

Uncontrolled changes to a project plan

Why

Unclear requirements and goals

Why

Deficient change management

Why

Poor communication

Resource Hugging

n. A type of scope creep where stakeholders believe they will never get these resources back on their project for a long time

Case Study

The New York Times Best Sellers

Case Study - Best Sellers

Project Overview:■ New design w/ NYT custom webfonts■ Switch to APIs backed data■ Ability to navigate to previous weeks

Case Study - Best Sellers

New design

Case Study - Best Sellers

API backed data

Case Study - Best Sellers

Case Study - Best Sellers

View previous week's lists

Case Study - Best Sellers

Case Study - Best Sellers

What went wrong from the start:■ Only "requirements" were the just the project

goals■ Product owner was really just business

development lead■ Features driven by design team

Case Study - Best Sellers

6 weeks in, launch approaching...

Case Study - Best Sellers

Case Study - Best Sellers

"But we want it to go back to 5 previous years worth of history"

■ API only supported 18 months■ Previously used data store wasn't organized to

be historic (was treated like an article in the paper, publish once and move on)

Case Study - Best Sellers

"Buy button should go directly to book URL"

■ Old application went to a "list" view on Amazon or local bookseller website

■ "Can you add in B&N links the week of launch, too?"

Case Study - Best Sellers

3 months in, we finally launched

A certain kind of scope creep

Wasn't just a desire for a more robust product, they were truly worried no developer team would touch their product for another two years

Primary scope creep

Initial scope creep should have been addressed

■ Actual requirements, not just "mimic" old logic■ Clearer tracking of changes■ More concrete milestone and launch dates

Resource hugging

Requires some additional strategies:

Resource hugging

Actually iterate■ Schedule a phase II for 2-3 weeks after launch■ Bug fixes, user feedback, etc■ Ensure items descoped from phase I are

addressed (or publicly cut) from phase II

Resource hugging

Matrix the developers, not the team■ Have an assigned team■ Members may swap teams■ Teams may expand or contract

Resource hugging

Close-out as important as kick-off■ Post mortem on negative impacts■ Discuss why features were left on the table■ Measure success and organize check-ins

Not just new projects

Resource hugging happens often on projects in "maintenance mode"

Maintenance mode

You decide to fix bugs or add features, but not make a new project

■ People come out of the woodwork with new requests -- "now is my only chance"

■ 1 week of "bugs" becomes a month of dragged out drudgery

Maintenance mode

Have a running backlog of bugs and new features

■ Keep it constantly up to date■ Draw a circle around the changes as part of this

"bug fix" round and stick to that list■ Any other bombardment of new request goes

into the queue for prioritization on the next round

Stop hugging me

Call out when resource hugging happens■ Refer to the rationale of other higher priorities,

make the plan of record known■ Be diligent in managing all aspects of scope

creep and resource hugging likelihood will be diminished

Questions?

Paul Robbins API Product ManagerKnewton

@robbinspaulpaul@knewton.com