Resource hugging presentation
-
Upload
robbinspaul -
Category
Technology
-
view
69 -
download
0
description
Transcript of Resource hugging presentation
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