4. Agile / Agile Methodology
Agile: able to move quickly and easily
In Development: An umbrella term for any
of a number of iterative, incremental
development processes or frameworks
Iterative development: incremental
development of smaller features with frequent
revisions. Encourages rapid and flexible
response to change.
5. Agile Manifesto
Individuals and interactions over Process and tools
Working software over Comprehensive documentation
Customer Collaboration over Contract negotiation
Responding to change over Following a plan
While there is value on the right, we value the items on the left more
8. Build a House: Waterfall Style
Imagine:
• Meet Client. Discuss full house requirements
• Design entire house
• Lay foundation for fully designed house
• Build frame
• Put in plumbing
• Wire electrical
• Complete exterior
• Complete interior
9. Build a House: Agile Style
Imagine:
• Meet Client. Discuss immediate need (shelter to sleep in)
• Design, build & test a bedroom (1 door to get in and out)
• Meet Client. Discuss next need (bathroom)
• Design, build & test a bathroom (attached to bedroom)
• Meet Client. Discuss next need (kitchen)
• Design, build & test a kitchen (attached to bathroom)
• Meet Client. Discuss next need (bedroom on 2nd floor)
• Ooops, need to teardown and rebuild - originally
designed for one level
10. Build a House: Notes
• Last slide poked fun at Agile, but that wasn’t the point
• Both Waterfall & Agile methodologies can result in waste
• Waterfall: May build the wrong thing, wrong time, not
fulfill a need
• Agile: May need to redo work due to lack of plan/
foresight. Can “spin wheels” doing work to get it right.
• With Agile, still helps to have a vision; helps to have some
idea where you are going to help further reduce waste
11. Benefits of Agile
• Greater ability to respond to change
• Greater transparency
• Greater predictability
• Reduced risk
• Constant Product and Process
Improvement
13. Scrum
• First described by Hirotaka
Takeuchi & Ikujiro
Nonaka in 1986 in the New
Product Development Game
• Based on case studies from
automotive, photocopier
and print manufacturing
• Formalized as Scrum in
1995 by Ken Schwaber &
Jeff Sutherland
14. Product
Owner
Product Owner:
The one who decides what gets built. Represents
the stakeholders and is the voice of the customer.
Responsible for maximizing value.
15. Product
Owner
Backlog Item: Has attributes of description,
order, estimate and value.
User Story:
A description that captures the user’s need (‘who’,
‘what’, and ‘why’) in a simple, concise way.
Written in the form of:
“As a {role}, I want a {goal/desire} so that I can
{benefit}.”
Example:
“As a car driver, I want a means to turn the car, so
that I can go around a bend in the road.”
Backlog Item
16. Item 2Item 3Item 4Item 5Item 6Item 1
Product
Owner
Product
Backlog
Product Backlog:
Prioritized list of user stories and “technical debt”.
Technical Debt is technical work to be completed
but which the user is not likely to notice. For
example, better organizing code for maintainability.
17. Item 1
Item 2
Item 3
Item 4
Item 5
Item 6
Product
Owner
Development Team: Cross-functional team
with all the skills necessary to create product
features (complete backlog items). Responsible
for delivering potentially shippable increments of
the product.
Sprint: One development cycle. Typically 2 to 4
weeks in length. The development team
commits to completing select backlog items each
sprint.
Some Quick Definitions
Product
Backlog
19. Item 1
Item 2
Item 3
Item 4
Item 5
Item 6
Product
Owner
Scrum Master:
Servant leader for the team. Ensures the
team uses agreed-upon scrum processes.
Removes impediments to Development
Team progress.
Similar to Project/Program Manager
Sprint
24 hr
Product
Backlog
Sprint
Backlog
20. Item 1
Item 2
Item 3
Item 4
Item 5
Item 6
Daily
Stand-up
Product
Owner Daily Stand-up:
Meeting in which each
team member gives a
brief status update of
what they did, what
they will do, and what
is blocking them.
Sprint
24 hr
Product
Backlog
Sprint
Backlog
21. Item 1
Item 2
Item 3
Item 4
Item 5
Item 6
Product
Owner
Definition of Done (DoD):
Team defined criteria by which a backlog
item is considered complete. Can include
things such as having automated tests in
place and features passing all automated
tests.
Sprint
24 hr
Working
Increment
Product
Backlog
Sprint
Backlog
23. Recap of Scrum Roles
Product Owner: Decides what is to be built. The voice of
the stakeholders. Responsible for maximizing product and
Development Team value. Similar to a Product Manager.
Development Team: Cross-functional team with all the
skills necessary to create product features. Responsible for
delivering potentially shippable increments of product every
sprint.
Scrum Master: Meeting facilitator and coach. Ensures the
team uses agreed-upon scrum processes. Removes
impediments to Development Team progress.
24. Scrum Meetings
Sprint Planning: Meeting in which the team figures out which backlog
items it can commit to completing for the coming sprint.
Daily Stand-up: Short meeting held every day during a sprint. Each team
member briefly describes what (s)he worked on, what (s)he will work on, and
any thing that is blocking them from working.
Sprint Review & Retrospective: Meetings in which the team
demonstrates completed work to stakeholders. The team also discusses what
went well, not so well and what they want to work on improving in the next
sprint (much like a post mortem).
Backlog Grooming: A meeting used to make sure the backlog is still
properly prioritized, break down larger stories, or get clarification on stories.
25. Other Common Terms
Story Points: An estimated measure given to a user story to judge
how much work the story is.
Velocity: The capacity of a team to handle story points in a sprint.
Over time an average can be determined of how many story points a
team typically completes in a sprint.
Burn-down chart: Chart that is updated every day to show the “burn
down” of the amount of work left in a sprint, plotted against the ideal,
linear burn-down rate.
Spike: A time boxed period in a sprint used to perform research or
create a prototype. A spike is complete when the time period ends. The
goal may or may not have been achieved in a spike.
26. Resources
• “Scrum: The Art of Doing Twice the Work in Half the
Time” by Ken Schwaber and Jeff Sutherland
• http://agilemanifesto.org
• http://scrumtrainingseries.com
• http://www.scrumguides.org
• http://www.scrum.org
• http://www.scrumalliance.org
• “Kanban: Successful Evolutionary Change for Your
Technology Business” by David J. Anderson
27. Kanban
• Developed by Taiichi
Ohno of Toyota in the
1950’s.
• Adapted for software by
David J. Anderson
• Based on the Theory of
Constraints introduced in
1984 in the book The Goal
by Eliyahu M. Goldratt
28. Kanban Key Principles
• Start with existing process
• Agree to pursue incremental, evolutionary change
• Respect current process, roles, responsibilities and
titles
• Leadership at all levels
30. Scrum vs. Kanban
Scrum Kanban
Cadence Fixed length Continuous flow
Roles
Product Owner,
Scrum Master
Development Team
No prescribed roles
Key Metrics Velocity Cycle time
Change Philosophy
Change only
between sprints
Change at any time
Level of Structure More structured Less structured
