1. Agile Product Design and
Project Management
Valentina Powers
Director of Digital Operations, NYPR
Bryan Young
Digital Project Manager, NYPR
Monday, September 24, 2012
2. Agenda
• The “traditional” project
• Traditional becomes Lean, Lean becomes Agile
• What is Agile?
• What is Scrum?
• Real-life applications of Agile
• Workshop: using Agile
Monday, September 24, 2012
4. “Traditional” Project
Management: Waterfall
“I believe in this concept, but the implementation
described above is risky and invites failure.”
- Dr. Winston Royce, creator of Waterfall
Monday, September 24, 2012
5. When Waterfall Works
• predictable, repeatable, certain processes and
requirements
• the next step is always known (linear)
• ex. accounting, payroll, billing.
Monday, September 24, 2012
6. When Waterfall Doesn’t
Work
• uncertain requirements
• change is inevitable
• the next step is not known! (non-linear)
• ex: strategy, marketing, web, software, most
things
Monday, September 24, 2012
7. From Waterfall to Lean
• Lean manufacturing and the modernization of
Mass Production
• Multi-disciplinary Lean approach: lightweight
and Agile
Toyota Production
Toyota propagates System Dell, IBM adopt The Agile
Lean (TPS) is launched lightweight Manifesto
1960 1970 1980 1990 2000 2010
Monday, September 24, 2012
11. What is Agile?
• a non-traditional approach to Project
Management that stresses collaboration,
flexibility, and quick, iterative cycles of
productivity
• adapted widely in software development but is
multi-disciplinary
Monday, September 24, 2012
12. Who Uses Agile?
Technology/Software Investment/Banking Media
Education Automotive Retail
12
Monday, September 24, 2012
13. What is Agile?
• focus is on needs and usability, not requirements
• acceptance of failures, learning to adapt
• Build - Measure - Learn: create feedback loops
• team input is crucial
Monday, September 24, 2012
14. What is Agile?
• Develop Minimum Viable Products (MVP)
• build simple products
• reduce goals, add later
• learn quickly
• prioritize features
• if it fails, that’s okay!
• more than 60% of software functionality
never used
Monday, September 24, 2012
15. The Agile Manifesto
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
• Individuals and interactions over processes and
tools;
• Working software over comprehensive
documentation;
• Customer collaboration over contract
negotiation;
• Responding to change over following a plan.
Monday, September 24, 2012
16. 12 Agile Principles
• Customer satisfaction by rapid delivery
• Welcome changing requirements, even late in
development
• Working software is delivered frequently (weeks
rather than months)
• Working software is the principal measure of
progress
• Sustainable development, able to maintain a
constant pace
• Close, daily co-operation between business
Monday, September 24, 2012
17. 12 Agile Principles
• Face-to-face conversation is the best form of
communication (co-location)
• Projects are built around motivated individuals,
who should be trusted
• Continuous attention to technical excellence
and good design
• Simplicity
• Self-organizing teams
• Regular adaptation to changing circumstances
Monday, September 24, 2012
18. Why Agile?
• Cost of change is minimal
• Focus from cost to revenue
• Time to market
• Better customer satisfaction
• Less process, more products
Monday, September 24, 2012
19. Why Agile?
• Greater visibility into project progress
• Early defect detection/prevention. Catch
mistakes early!
• Adaptive/flexible: lessons learned at every
iteration
• Stress is on creating quality products
• Improved team morale
Monday, September 24, 2012
20. The downsides (and upsides)
of Agile
• Need for organizational support / organizational
efficiency across the board
• Focus on shorter sprints vs. big picture / keep
momentum
• Change fatigue from users / change is good!
• Less documentation / documentation is not the
primary vehicle of communication
Monday, September 24, 2012
23. Scrum
• an Agile project management process stressing
collaboration and flexibility
• an iterative approach to product development,
when requirements are uncertain or constantly
changing
• a method by which to keep an ongoing dialog
between users and creators
• scalable to distributed, large and long projects
Monday, September 24, 2012
24. Scrum Roles
Scrum Master
• manages the process
• shields the team from distractions
Product Owner
• manages the vision, ROI, releases
• updates and prioritizes requirements
Team
• manages the development; commits to results to be achieved
• self-organizing and self-managed; determines the best way to deliver
the highest priority features
Monday, September 24, 2012
25. Scrum Terms
Sprint
• an iteration (or short burst) of work
• typically 14 days in duration: deliverables are built
Product Backlog
• to-do list (list of functionality) for a particular product, managed and
prioritized by the client
Sprint Backlog
• to-do list (list of functionality) for a particular sprint, managed and
prioritized by the team
Monday, September 24, 2012
26. Scrum Terms
User story
• As a <role>, I want <functionality> so that <value or justification>.
Daily scrum
• daily stand-up
Burndown chart
• a big picture view of a project
PSP / MVP
Monday, September 24, 2012
29. Why Did We Go Agile?
• It’s a movement/trend in Software Development
with traction
• Proven to be successful
– 1 in 7 companies using Agile (2005)
– NPR and other media companies use Agile
• Growing NYPR digital staff with lots of projects
• Allows us to move quickly, be innovative, launch
better products.
Monday, September 24, 2012
30. How We Did It
• Co-location
If we don’t all sit together,
• Training we will fail!
• Projects split into releases, releases split into
sprints
• Daily scrums
• Split up into smaller project teams; more
developer involvement
• Work closer with internal clients & collaborate-
more transparency
Monday, September 24, 2012
31. How We Did It
• Lessons learned
• Integration of feedback loops
• Collaborative tools to share information (JIRA,
Trello, rapid boards, white boards, etc.)
• Use contractors who are known "partners" and
have an existing relationship
Monday, September 24, 2012
37. How We Did It
• Take more risks (failure is OK!)
– Allows us to be innovative
• Create teams with people who work well together,
self-managed teams with generalists (team
members wear multiple hats)
– Synergy is key
Monday, September 24, 2012
38. In the Works...
• Hold internal hackathon, 20% built into sprints:
ways developers can explore projects.
– Keeps creative juices flowing.
• More Prototypes, less comps-
– Solve problems before we hit dev
• More MVP’s-”minimum viable products”
– Simple now, evolve later
– Helps us move faster
Monday, September 24, 2012
41. In the Works...
• Developers blog & feedback forms
– Transparency with our users, more feedback
loops
• More guerilla testing!
– Quick feedback at lower costs
Monday, September 24, 2012
42. Case study: The Lean
Newsroom
• Problems:
• too many communication channels, not
enough accountability
• who owns what and how do we know who
owned what?
Monday, September 24, 2012
43. Case study: The Lean
Newsroom
• Task: develop a better way to monitor the
progress of a story from inception to execution
• improve transparency and communication
• allow for easy determination of ownership and
accountability
• reduce waste
Monday, September 24, 2012
44. Case study: The Agile NYPR
Newsroom
Monday, September 24, 2012
45. How can you be Agile?
• Create small, empowered, self-organized teams
that can make quick decisions, but keep
stakeholders in the loop
• Team members made up of generalists:
competent and eager to learn
• Use existing Agile tools to streamline
communication and collaborate
Monday, September 24, 2012
46. How can you be Agile?
• start simple - don’t overthink - test the waters -
think MVP
• break down large projects into smaller parts
• set goals, not hard requirements
• think of your audience’s needs
• take risks (it’s okay to fail!)
Monday, September 24, 2012
47. How can you be Agile?
• learn lessons: “how did we do?”
• incorporate feedback loops in subsequent
iterations
• be quick to respond to change - flexibility is key
• get trained!
Monday, September 24, 2012
48. Recommended Reading
• “Agile Software Development with Scrum” by
Ken Schwaber
• “Succeeding with Agile: Software Development
Using Scrum” by Mike Cohn
• “Extreme Programming Explained” by Kent
Beck
• “Agile and Iterative Development” by Craig
Larman
• The Scrum Alliance: http://
www.scrumalliance.org/
Monday, September 24, 2012
52. Let’s be Agile!
Now that you’ve learned what Agile is, let’s put it into practice by creating a
menu using Agile techniques.
You will...
• Be part of an Agile team
• Create user stories
• Size and prioritize the backlog
• Do the sprint
• Review / retrospect
Monday, September 24, 2012
53. Break into teams!
• (4-5 to a team, please.)
• Appoint one Scrum Master, one Product
Owner + team
Monday, September 24, 2012
54. Choose Your Requirements
• Create cover art/brand/logo
• Menu layout
• Create categories
• Provide drink options
• Location/map
• Set pricing structure
• Contact information
• Delivery information (minimum and delivery area)
• Provide satisfied customer testimonial
• Provide ratings (Zagat/Yelp)
• Provide hours of operation
• Provide photo of the restaurant
• Menu material (paper/covering)
• Separate delivery/take out menu
• Website/digital menu
• Daily specials
Monday, September 24, 2012
55. User Stories
20 minutes
• Write 3 user stories for each of your
requirements for this sprint.
• Example: As a customer, I want to be able
to see what beverages are available so that
I can purchase something to drink with my
dinner.
Monday, September 24, 2012
56. Size and Prioritize
20 minutes
• Do a round of time estimates for items in the
backlog, based their relative complexity
• Assign a point value to each PBI
• Range: 0 (no effort) 1/2 (tiny effort), 2 (small
effort), 3 (medium effort), 5 (big effort), 8 (very
big effort), 13 (huge effort), 20 (forget about it)
Monday, September 24, 2012
57. Sprint
20 minutes
• Assign each user story to a team member
• Sprint away!
• (Incorporate “daily SCRUM” ) - 2 mins
Monday, September 24, 2012
58. Now let’s...
• BREAK!
Monday, September 24, 2012
59. Review
• Meeting in which the team demonstrates
the work they have completed
• Typically 2 hours for each 14 day sprint
• Team presentations!
Monday, September 24, 2012
60. Retrospective
• What went well and what didn’t? How
can we improve for next time?
• Typically 90 minutes for 2 week sprint
• 4 Square
Monday, September 24, 2012
61. Thank you!
• Questions for us?
• How will you apply it?
Monday, September 24, 2012