Agile presentation ONA12

Agile Product Design and Project Management

Valentina PowersDirector of Digital Operations, NYPR

Bryan YoungDigital 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

1960 1970 1980 1990 2000 2010

Toyota propagates Lean

Toyota Production System

(TPS) is launched

Dell, IBM adopt lightweight

The Agile Manifesto


II. What Agile Is


What is Agile?


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


http://www.scrumalliance.org/pages/who_uses_scrum

http://www.scrumalliance.org/pages/who_uses_scrum

Who Uses Agile?Technology/Software

12

Education

Investment/Banking

Automotive

Media

Retail


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

• Individuals and interactions over processes and tools;

• Working software over comprehensive documentation;

• Customer collaboration over contract negotiation;

• Responding to change over following a plan.

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:


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

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/flexible: 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 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


Agile Techniques

• Extreme Programming (XP)

• DSDM

• FDD

• Lean

• ...and Scrum


III. Scrum


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


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


http://www.flickr.com/photos/meherenow/2848857702/in/set-72157607233237865/




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


http://upload.wikimedia.org/wikipedia/commons/8/8c/Burn_down_chart.png

http://upload.wikimedia.org/wikipedia/commons/8/8c/Burn_down_chart.png

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

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


If we don’t all sit together,we will fail!

How We Did It

• Co-location

• Training

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


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 - flexibility 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/


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 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


User Stories

• 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.

20 minutes


Size and Prioritize

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

20 minutes


Sprint

• Assign each user story to a team member

• Sprint away!

• (Incorporate “daily SCRUM” ) - 2 mins

20 minutes


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

Technology

Transcript of Agile presentation ONA12