• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Agile Project Management at The Washington Post

Agile Project Management at The Washington Post



The story of how The Washington Post moved from waterfall to agile methodology for the creation of a new product: TastePost.

The story of how The Washington Post moved from waterfall to agile methodology for the creation of a new product: TastePost.



Total Views
Views on SlideShare
Embed Views



10 Embeds 93

http://daveburke.com 34
http://www.daveburke.com 28
http://www.slideshare.net 13
http://askqtp.blogspot.com 8
http://www.askqtp.com 3
http://www.linkedin.com 2
http://dnkb.squarespace.com 2
http://static.slidesharecdn.com 1
http://www.pickpdf.com.local2 1
http://dave-e-burke.squarespace.com 1


Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment

    Agile Project Management at The Washington Post Agile Project Management at The Washington Post Presentation Transcript

    • Innovation through Iteration
    • Background
    • Background
    • Washington Post IT Unit • About 140 people • Supports operations of the newspaper and some operations at other Washington Post Company affiliates, including: • Publishing • Advertising • Circulation • Syndication • Accounting • Production
    • Washington Post Web Solutions
    • Traditional projects flowed like a waterfall http://flickr.com/photos/24028533@N03/2297190795/
    • The Waterfall: Measure twice, cut once • Requirements Doc • Known specs • Wireframes • Architecture Diagrams Discovery • Working Build Design • Test Scripts Development • Discrete phases Testing • Launch • Tight discipline Deployment • Specific and unchanging requirements • Design and development standards The goal: Build the thing right.
    • Waterfall works well for large-scale projects • When it's familiar territory • Involve high levels of integration with existing systems • When working prototypes for user feedback are more expensive or difficult to produce (e.g., non-web)
    • Waterfall projects ! Familiar territory ! Simple transactions ! Integration with DSI
    • Waterfall projects " Familiar territory " Simple transactions " Integration with PAS
    • Potential effects of waterfall projects • Simplified project governance (Senior Management) • Bigger projects mean fewer per year to track • Fixed scope keep stakeholders/project team aligned • Hoarding of IT resources through project bloat (at Discovery) • More risk that changing business needs will outpace development • Inaccurate LOE and schedule estimates • Tendency toward "Launch and move on" mentality
    • Effect on project managers
    • Effect on project managers
    • When things go wrong in the waterfall “By the time the site launched it looked completely different from what we had envisioned.” – Designer “We had to cut some corners – documentation, user testing, support training – but we made the date.” – Project Team “By the time the project finished, the business needs had totally changed.” – Business Analyst “If I knew in the beginning what I know now, we would have made a very different site.” – Business Client “Hey, you approved it.” – PM
    • Knowledge gap when building unknown solutions knowledge volume decisions Discovery Design Development Testing Deployment v1.0
    • So that was then. . . . 16
    • Business in transition
    • Business in transition
    • Strategic Focus: Innovation •“We actively develop new revenue streams from non-traditional sources.” •“We introduce and support new brands, selectively, when we believe that doing so allows us to achieve the full potential an opportunity may afford.” •“We make bets on ideas that can have material impact even if they entail high risk. We invest in small-scale experiments to learn more about areas of strategic opportunity where uncertainty is high. More than ever, responsible innovation is necessary for our success.” •“Because of the high level of marketplace uncertainty, we regularly monitor and revisit our strategies, being willing and
    • Where IT comes in Align our methodologies to support innovation. . . • Partner with the business to explore and realize new revenue streams • Enable those “bets” and “small-scale experiments” • Improve speed to market; bring value faster . . . While we remain true to our core mission of supporting the traditional business
    • A shift in emphasis Waterfall: Build the thing right. Iterative: Build the right thing.
    • An alternate approach: Iterative T I M E Discovery Design Development Testing Deployment v1.0
    • An alternate approach: Iterative ß ß ß ß ß T I M E • Better fit for product innovation • Speed to market with beta releases • Betas prove/refine the concept • Earlier value generation • More user feedback, which guides the next iterations The goal: Build the right thing.
    • Iterative vs. incremental http://www.flickr.com/photos/spielzimmer/429215172/ Got the whole brick wall metaphor from Jeff Patton talking to Jared Spool. http://www.uie.com/brainsparks/2008/08/05/spoolcast-ux-in-an-agile-environment-with-jeff-patton/
    • Why Vine? • Looked at many topics • Beer/Wine/Spirits meets three criteria: • Consumer Passion • Advertiser dollars in market that we don’t get • Consumer spending • Negatives • Variation in state laws (MD/VA/DC) • Local retailer needs • Is the universe of local wine lovers large enough?
    • Initial idea
    • Pilot project: Vine
    • The Vine Betas • Registration • User Profiles • Coupons • Product blog • Analytics • Credit Card • Program info • Monitoring • Wine organizer • Vine content • Customer feedback • Chat • Social Networking
    • The Vine Betas
    • Scrum training and adoption
    • Scrum roles and deliverables • Product backlog • Single product owner on the business side who is part of the team • 30-day sprints • Self-managing teams • Technically, no project manager. Instead, ScrumMaster. • Streamlined documentation
    • Product backlog
    • Sprint task list
    • System Documentation
    • Member home page
    • Featured Selections/Discounts
    • Member Content/Events
    • “My bar/cellar”
    • Store/Retrieve bottles
    • Thoughts/Lessons so far 40
    • Challenges/Risks with iterative products • Do you ever get the feeling that you’re surrounded by total and complete chaos? • Organizational inertia, cultural change • Integration with enterprise systems • Transition from Beta to bulletproof • Abandoning unsuccessful Betas
    • Sprint zero is critical.
    • Not every iteration is a public release http://www.flickr.com/photos/42dreams/2452861482/ http://www.flickr.com/photos/cursedthing/448971179/ http://www.flickr.com/photos/basykes/34279052 http://www.flickr.com/photos/ayelie/441101223/
    • Not every iteration is a release http://www.flickr.com/photos/kellysue/2831068087/ http://www.flickr.com/photos/clevercupcakes/3229153310/ http://www.flickr.com/photos/bossacafez/268979524/ http://www.flickr.com/photos/flirtykitty/9226535/ http://www.flickr.com/photos/basykes/34279052
    • Modular code enables re-use ß ß ß Credit Card Google Maps Shopping Cart Processing Integration ß ß ß Social Mobile Text Networking Browsing Messaging ß ß Rating/ Video Player Reviewing
    • Iterative works well. . . • When the feature set is evolving • Bets on ideas; small-scale experiments • Minimal IT investment • Low-cost failure • Because it’s in line with the advantages of the web • Easier to update, enhance, evolve • Instant customer feedback • Incremental releases of new functionality (Betas) • Product improves as more people use it
    • That’s it. 47
    • Contact Dave Burke dave@daveburke.com twitter.com/daveburke 47