This document provides an overview of Agile development principles and practices. It discusses how Agile originated as a reaction to waterfall development methods. Key aspects of Agile include iterative development, self-organizing cross-functional teams, and continuous improvement through practices like daily stand-ups and retrospectives. The document also compares Agile software development to Toyota's lean production system, noting similarities like just-in-time delivery and eliminating waste. Finally, it provides details on how a company called PayPerks has implemented Agile practices in their development process.

1. 1
CONFIDENTIAL – Not to be distributed
What do making cars and writing software
have in common?
February 11, 2014
Tim Dybvig
Director, Product Management

2. 2
CONFIDENTIAL – Not to be distributed
What do making cars and writing software have in common?
• What is Agile?
• Manifesto for Agile Software Development
• An unlikely history: cars and supermarkets
• Becoming agile: Toyota Production System
• What do making cars and writing software have in common?
• A note about output: how to measure software
• Agile at PayPerks
• How can you use Agile?

3. 3
What is Agile?

4. 4
What is Agile?
• The old way: Waterfall methodology
weeks / months / years

5. 5
What is Agile?
• The new way: Agile development

6. 6
What is Agile?
• The Agile movement came about in the mid 1990s as a reaction to
waterfall and older, ineffective methods
• Several versions and names over the years:
• Unified Process
• SCRUM
• XP (Extreme Programming)
• Adaptive Software Development
• Feature Driven Development
• February 2001 in Snowbird, Utah: 17 notable software developers
gather to create: Manifest for Agile Software Development
• Principles and guidelines; not prescribed process

7. 7
http://agilemanifesto.org/

8. 8
An unlikely history: cars and
supermarkets

9. 9
An unlikely history: cars and supermarkets
“Catch up with America in three years. Otherwise, the
automobile industry of Japan will not survive.”
- Kiichiro Toyoda, President of Toyota Motor Company, 1945

10. 10
An unlikely history: cars and supermarkets
• Early automobile manufacturing: “mass production” by Henry Ford, in 1913
• efficiency of batch production by way of standardization (no more colors!)
• Taiichi Ohno was a plant manager, decided to improve Toyota process
• Inspired by a visit to US supermarkets in the 1950s
• He noticed a supermarket customer gets:
• What is needed
• At the time it’s needed
• In the amount needed
• Became obsessed with “just in time” delivery
• Only make what is needed, when it’s needed
• Decrease waste
• Lower cost
• Increase meaningful output
• The result?
• Toyota Production System (…..after many, many years of trying!)

11. 11
Becoming agile: Toyota Production
System

12. 12
Becoming agile: Toyota Production System
“Just in time”

13. 13
How did Taiichi Ohno implement “just in
time” manufacturing at Toyota?
A: 15 years of continuous improvement
Becoming agile: Toyota Production System

14. 14
Becoming agile: Toyota Production System
Flow & Management by sight
• Machines are moved to accommodate actual workflow
• Floor managers in factories should be able to clearly see all processes
• Allows for easy spotting of blockages and interruptions
Orders made using Kanban (“sign board”) cards
• Piece of paper with order information, travels with the requested parts
• "simple and direct form of communication always located at the point where it
is needed"

15. 15
Becoming agile: Toyota Production System
Cross functional workers
• “many skilled” workers
• workers learn how to operate many machines, not just one type
Small lot sizes, and quick setups
• New part setup can be performed in minutes, not hours
Production leveling
• Break down monthly production levels into weekly, monthly pieces
• Prevents waste and burnout

16. 16
Becoming agile: Toyota Production System
Elimination of waste
• reduce repetitive work
• reduce over-production: stop making what is not needed
Five “why”s
• Ask why five times to get to the root cause of a problem
• "5 why's equal one how”
Kaizen: continuous improvement
• Iterative improvements over time as the production process changes

17. 17
So….
What do making cars and writing
software have in common?

18. 18
What do making cars and writing software have in common?
Making cars Writing software
Old way
“Mass production”
• efficiency of scaled processing
• highly standardized
• lack of variation and options
• “push” system based on static
assumptions: make as many cars
as possible
“Waterfall planning”
• performed in discrete, batch phases
• projects last months or years
• poor communication between phases
• also based on very static view of the
world – business requirements often
out of date by release
New way
“Toyota Production System”
• “just in time” delivery of cars
• allows for flexibility of products
• constantly changes and evolves
• “pull” system based on actual
customer requirements
“Agile development”
• “just in time” delivery of software
• software is delivered in days/weeks
• flexible and iterative
• creates a system that allows for
constantly changing business and
customer priorities

19. 19
What do making cars and writing software have in common?
Flow & Management by sight
• Machines are moved to accommodate actual workflow
• Floor managers in factories should be able to clearly see all processes
• Allows for easy spotting of blockages and interruptions
Orders made using Kanban (“sign board”) cards
• Piece of paper with order information, travels with the requested parts
• "simple and direct form of communication always located at the point where it
is needed"
“Kanban board” showing all development work in progress
• Each story, bug or chore is written up on its own index card
• A card has the story title, lookup ID, and points (if a feature)
• As the development work moves through the process (backlog, in process, in
QA, delivered), the cards are moved across the board
• Allows us to clearly see blockages, backups and interruptions in our process

20. 20
What do making cars and writing software have in common?
Cross functional workers
• “many skilled” workers
• workers learn how to operate many machines, not just one type
Small lot sizes, and quick setups
• New part setup can be performed in minutes, not hours
Production leveling
• Break down monthly production levels into weekly, monthly pieces
• Prevents waste and burnout
Common Agile practices:
• cross functional, self organizing teams
• break down features and products into smallest working pieces for delivery
• create and maintain a consistent “velocity” that allows for a better business
planning with a sustainable pace of work

21. 21
What do making cars and writing software have in common?
Elimination of waste
• reduce repetitive work
• reduce over-production: stop making what is not needed
• produce less defective parts
Five “why”s
• Ask why five times to get to the root cause of a problem
• "5 why's equal one how”
Kaizen: continuous improvement
• Iterative improvements over time as the production process changes
Common Agile practices:
• Constant refactoring and DRY (“don’t repeat yourself”), eliminate code waste
• Continuous integration and full test coverage
• Dedicated QA teams focused on high quality output
• Regular retrospectives and showcases to improve the team and process

22. 22
A note about output: how to
measure software

23. 23
A note about output: how to measure software
It’s easy to see how many cars you just made, but
how do we measure the “output” in software?
A: Points

24. 24
A note about output: how to measure software
Points
• An estimation of complexity, not time, assigned to each feature
• People are bad at estimating, but we’re at least consistent
• Points assigned to user-facing features that create business value
Velocity
• The number of points a team can deliver in an iteration
• Used for business and sprint planning
• Thermometer for team health: if velocity drops, something is wrong
• While not a perfectly scientific system, it gives a sense of "yesterday's weather”

25. 25
Agile at PayPerks

26. 26
Agile at PayPerks

27. 27
Agile at PayPerks: Week-long Sprints
• One week sprints, with weekly deploys
• Initially tried two week sprints, but the bi-weekly rhythm was inconsistent
• Kanban board on the wall with index cards for all stories in progress
• Features = yellow
• Bugs = red
• Chores / tech debt = blue
• Use post-its on cards when a story is blocked
• Daily stand ups
• PayPerks + Arbisoft team on Google Hangout
• PayPerks team around the kanban board
• Other best practices:
• pairing and cross functional teams
• Constantly evaluate new tools for use (Boxen, Vagrant, Fabric, etc)
Daily stand up

28. 28
Agile at PayPerks: Weekly Sprint Meetings
• Pokering
• Assigning point values to features in the backlog as a group
• Using playing cards in a Fibonacci sequence (1, 2, 3, 5, 8)
• Everyone shows their guess, group discusses to reach consensus
• Retrospective
• Write up post-it notes for what went well, and what didn’t
• Green = good; red = bad
• Group the red post-its, and choose one “theme” to improve in the next sprint
• Showcase
• Present the features that were completed that iteration to the business
• Sprint planning
• Review the backlog for the next iteration
• Make sure the team is comfortable committing to the work

29. 29
Agile at PayPerks: Development Tools
• Stack: Python/Django, PostgreSQL, Gunicorn, Nginx, AWS (Amazon Web Services)
• Dev IDE: PyCharm
• CI Server: TeamCity
• 4 cloud-based agents that run entire test suite in a few minutes
• Integrates with PyCharm for ease of debugging broken tests, testing local
builds, etc
• Code Repo: GitHub
• Planning: PivotalTracker & Physical Kanban board
• User stories, requirements and sprint planning
• Integrated with GitHub, so all Git commits are linked to each story
• Stories are written by the product team, reviewed and pokered by
engineering
• “vertically sliced” stories and features
• Comms:
• HipChat to promote constant communication, even when remote
• Google Hangouts

30. 30
Agile at PayPerks: PivotalTracker
High level story info
- Title
- ID / link
- points
- status
- requester / owner
Story details
- use cases
- business requirements
- acceptance criteria
Commits and comments
- all Git commits
- comments, questions,
clarifications

31. 31
Agile at PayPerks: PivotalTracker
Velocity
Automatically groups sprints based on
the team velocity, and point value of
stories; makes sprint planning very easy
Stories ready for QA
Work in progress Work not yet started
Hash marks are
point values of
each story

32. 32
Agile at PayPerks: Kanban boards

33. 33
Agile at PayPerks: Kanban boards

34. 34
Agile at PayPerks: Kanban boards

35. 35
How can you use Agile?

36. 36
How can you use Agile?
However it works for you!
Try our process to see if it works for you. If it doesn’t, change
it until you find something that does.
“At regular intervals, the team reflects on how to become more effective, then tunes
and adjusts its behavior accordingly.”
- 12th (and final) Principle of the Agile Manifesto