Agile presentation ONA12

Agile Product Design and
Project Management

Valentina Powers
Director of Digital Operations, NYPR

Bryan Young
Digital Project Manager, NYPR

Monday, September 24, 2012

Agenda

• The “traditional” project

• Traditional becomes Lean, Lean becomes Agile

• What is Agile?

• What is Scrum?

• Real-life applications of Agile

• Workshop: using Agile


I. Before Agile


“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


When Waterfall Works

• predictable, repeatable, certain processes and
requirements

• the next step is always known (linear)

• ex. accounting, payroll, billing.


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


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


II. What Agile Is


What is Agile?


What is Agile?

• a non-traditional approach to Project
Management that stresses collaboration,
ﬂexibility, and quick, iterative cycles of
productivity

• adapted widely in software development but is
multi-disciplinary


Who Uses Agile?
Technology/Software Investment/Banking Media

Education Automotive Retail

12


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


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


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.


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

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


Why Agile?

• Cost of change is minimal

• Focus from cost to revenue

• Time to market

• Better customer satisfaction

• Less process, more products


Why Agile?

• Greater visibility into project progress

• Early defect detection/prevention. Catch
mistakes early!

• Adaptive/ﬂexible: lessons learned at every
iteration

• Stress is on creating quality products

• Improved team morale


The downsides (and upsides)
of Agile
• Need for organizational support / organizational
eﬃciency 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


Agile Techniques

• Extreme Programming (XP)

• DSDM

• FDD

• Lean

• ...and Scrum


III. Scrum


Scrum

• an Agile project management process stressing
collaboration and ﬂexibility

• 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


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


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


Scrum Terms

User story

• As a <role>, I want <functionality> so that <value or justiﬁcation>.

Daily scrum

• daily stand-up

Burndown chart

• a big picture view of a project

PSP / MVP


What Scrum Looks Like


IV. Real-life applications of Agile


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 staﬀ with lots of projects

• Allows us to move quickly, be innovative, launch
better products.


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

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


RAPID Board


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


In the Works...

• Hold internal hackathon, 20% built into sprints:
ways developers can explore projects.
– Keeps creative juices ﬂowing.
• More Prototypes, less comps-
– Solve problems before we hit dev
• More MVP’s-”minimum viable products”
– Simple now, evolve later
– Helps us move faster


Specifications- On Demand Player


In the Works...

• Developers blog & feedback forms
– Transparency with our users, more feedback
loops

• More guerilla testing!
– Quick feedback at lower costs


Case study: The Lean
Newsroom

• Problems:

• too many communication channels, not
enough accountability

• who owns what and how do we know who
owned what?


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


Case study: The Agile NYPR
Newsroom


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



• 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!)



• learn lessons: “how did we do?”

• incorporate feedback loops in subsequent
iterations

• be quick to respond to change - ﬂexibility is key

• get trained!


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/

Q&A

• Questions?

• Thoughts?

• Feeling nimble?


and now...

• BREAK!!


V. Activity: Creating a Menu


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


Break into teams!

• (4-5 to a team, please.)
• Appoint one Scrum Master, one Product
Owner + team


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 satisﬁed 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


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.


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)


Sprint
20 minutes

• Assign each user story to a team member
• Sprint away!
• (Incorporate “daily SCRUM” ) - 2 mins


Now let’s...

• BREAK!


Review

• Meeting in which the team demonstrates
the work they have completed
• Typically 2 hours for each 14 day sprint
• Team presentations!


Retrospective

• What went well and what didn’t? How
can we improve for next time?
• Typically 90 minutes for 2 week sprint
• 4 Square


Thank you!

• Questions for us?
• How will you apply it?


Agile presentation ONA12

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (18)

Similaire à Agile presentation ONA12

Similaire à Agile presentation ONA12 (20)

Dernier

Dernier (20)

Agile presentation ONA12