This document provides an introduction to Agile project management frameworks like Scrum and Kanban. It discusses the limitations of traditional waterfall project management and how Agile aims to address these issues through iterative development, collaboration, and flexibility. Key aspects of Scrum like roles, events, artifacts, estimation and user stories are explained. Kanban concepts such as visualizing workflow, limiting work in progress, and managing flow are also covered. The document recommends resources for learning more about Agile, Scrum, Kanban and hybrid approaches.

1. Introduction to Agile
Scrum, Kanban, and everything in between
Pravin Singh

2. The world before Agile

3. The world before Agile
Safeguard – Anti-Ballistic Missile Defense System
• 1969 – 1975, 5407 person years
• Cost: $25 Billion (not adjusted)
• The project was delivered according to specifications

4. The world before Agile
Safeguard – Anti-Ballistic Missile Defense System
• 1969 – 1975, 5407 person years
• Cost: $25 Billion (not adjusted)
• The project was delivered according to specifications
Operational for 133 days, project terminated in 1978
By the time the 6 year anti-missile system project was completed, the new
missiles were faster than the anti-missile missiles.

5. Then came Agile
• Iterative, Incremental, based on Inspect & Adapt
• Focuses on fail-fast
• Very Lightweight – focused on working software, not on processes
• Requirements evolve over time
• So does Design
Humphrey’s Law: Users will never know what they want until they see it
in production.

6. The Iron Triangle - Waterfall
Scope
Schedule Cost
Plan
Driven

7. The Iron Triangle - Agile
Scope
Schedule Cost
Value
Driven

8. Delivery
Verification
Work Breakdown - Agile
Requirements
Design
Implementation
Feature1
Feature2
Feature3
Feature4
Feature5
Feature6
Feature7
Feature8

9. Painting the Mona Lisa - Waterfall

10. Painting the Mona Lisa - Agile

11. Why Agile
• Helps handle changing requirements and priorities
• Lowers cost of change
• Provides better visibility into project progress
• Reduces risk
• Maximizes Return on Investment (business value prioritization)
• Delivers business value early and often

12. 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
That is, while there is value in the items on
the right, we value the items on the left more.

13. Agile Values and Principles
• Our highest priority is to satisfy the customer through early and continuous
delivery.
• Welcome changing requirements. Agile processes harness change for the
customer's competitive advantage.
• Business people and engineers must work together daily throughout the project.
• Build projects around motivated individuals. Give them the environment and
support they need, and trust them to get the job done.
• The most efficient and effective method of conveying information to and within
a team is face-to-face conversation.

14. Agile Values and Principles
• Working software is the primary measure of progress.
• Agile processes promote sustainable development. The sponsors, engineers,
and users should be able to maintain a constant pace indefinitely.
• Simplicity--the art of maximizing the amount of work not done--is essential.
• The best architectures, requirements, and designs emerge from self-
organizing teams.
• At regular intervals, the team reflects on how to become more effective, then
tunes and adjusts its behavior accordingly.

15. Flavors of Agile
Agile
Scrum
Kanban
XP
FDD
Crystal

16. When Agile works best
• Unclear/evolving requirements
• Changing priorities
• Customer availability
• Collocated team
• Flexible funding (like Time & Material contracts)

17. When Agile does NOT work so well
• Firm Fixed Price (all-or-nothing) contracts
• Different vendors for different phases
• Unavailability of customer
• Stable, upfront requirements

18. Game Time☺
All talk and no play
makes session a dull affair

19. Scrum

20. Scrum in a nutshell

21. Scrum Roles
Product Owner
• Voice of customer
• Owner of the Product Backlog
• Prioritizes the items to best achieve goals and missions
• Optimizes the work of the development team

22. Scrum Roles
Development Team
• Cross-functional
• Self-organizing, self-managed
• Has no sub-teams and no titles (other than team member)
• Generally of size 3-9 members

23. Scrum Roles
Scrum Master
• A servant-leader for the team
• Removes impediments
• Facilitates Scrum events
• Helps Product Owner maintain the backlog
• Coaches and guides

24. Scrum Events
• The Sprint
• Sprint Planning
• Daily Scrum (Standup)
• Sprint Review (Demo)
• Retrospective

25. Scrum Artifacts
Product Backlog
• Ordered list of requirements
• A living document (is never complete)
• Per Product, not per Team
• Owned by the Product Owner
Sprint Backlog
• Items selected for the Sprint
• Only team can change it during Sprint

26. Estimation& Velocity
• Hours/ Days
• T-shirt sizes
• Story Points
 Estimation is relative, not absolute
 The purpose is only to help plan the sprints, nothing else

27. Scrum Board
Backlog Conceptual
Design
Schematic
Design
Construction
Docs
Done
User
Story 1
User
Story 2
User
Story 3
User
Story 4
Task 4
Task 2
Task 3
Task 1
Task 5
Task 4
Task 3 Task 2
Task 1
Task 4 Task 3 Task 2
Task 1
Task 2 Task 3
Task 1

28. Burndown Chart

29. User Stories - Why
• Requirements are a communication problem.
• If business side dominates, functionality and dates are mandated with
little regard for reality.
• If engineers dominate, technical jargon replaces the language customers
can understand.
• Many customers cannot articulate their needs until they see something.
You built
what I asked
for, but it’s not
what I need.

30. User Stories - What
The 3 C’s
• Card – stories are traditionally written on notecards, and these cards can
be annotated with extra details
• Conversation – details behind the story come out through conversations
with the Product Owner
• Confirmation – acceptance tests confirm the story is finished and
working as intended

31. Anatomy of a User Story
• “As a <role>, I want <feature> so that <benefit>.”
• “In order to <receive benefit> as a <role>, I want <feature>.”
• “As a <role>, I want <feature> so that <benefit>. I’ll know it’s done when
<acceptance criteria>.”
• “As a <role>, I want <feature>.”

32. “INVEST” in good User Stories
• I – Independent (of all others, to the extent possible)*
• N – Negotiable (not a specific contract for features)
• V – Valuable (to the business, or to the end user)
• E – Estimable (to a good approximation)
• S – Small (enough to fit within an iteration)*
• T – Testable (in principle, even if there isn't a test for it yet)
* The more we break the stories down to make them smaller, the more difficult it becomes to keep them
independent. It’s a tread-off we should be aware of, and balance independence with size.

33. …and “SMART” Tasks
• S – Specific
• M – Measurable
• A – Achievable
• R – Relevant
• T – Time-boxed

34. How to create User Stories?
• Start with Users
• Create Personas with goals
• Derive Epics from Persona Goals
• Progressively decompose Epics into User Stories
• Make the Stories ‘Ready’ (clear, feasible, testable)
• Add Acceptance Criteria

35. Scrum Tools
• Rally (now CAAgile Central)
• IceScrum
• Taiga
• YouTrack
• Hansoft
• JIRA

36. Game Time☺
All talk and no play
makes session a dull affair

37. Kanban

38. Kanban in a nutshell
• Developed as a scheduling system in Toyota for lean manufacturing
• A delivery flow system that limits the amount of work in progress (WiP)
by using visual signals
• Work is “pulled” into the system when other work is completed and
capacity becomes available, rather than “pushed” into it when new work
is demanded.

39. 3 simple rules
• Visualize Workflow
• Limit WIP (Work in Progress)
• Manage Flow

40. Why Kanban
• Sometimes time-boxing doesn’t work
• Easy integration with other processes
• Does not mandate cross-functional team
• Minimal entry barrier

41. Creating a Kanban board
Backlog In Progress Done

42. Creating a Kanban board
Backlog In Progress
4
Done

43. Creating a Kanban board
Backlog Ready
2
In Progress
4
Done

44. Creating a Kanban board
Backlog Ready
2
Conceptual
Design
1
Schematic
Design
2
Construction
Docs
3
Done

45. Creating a Kanban board
Backlog Ready
2
Conceptual
Design
1
Schematic
Design
2
Construction
Docs
3 Done
Doing Done Doing DoneDoing Done

46. Creating a Kanban board
Backlog Ready
2
Conceptual
Design
1
Schematic
Design
2
Construction
Docs
3 Done
Doing Done Doing DoneDoing Done Swim lanes
based on
Priority/
Due date/
Nature of
work

47. Cumulative Flow Diagram

48. Kanban Tools
• LeanKit
• YouTrack
• Hansoft
• Rally (now CAAgile Central)
• JIRA

49. Scrumban

50. Scrumban in a nutshell
• Can be used for transitioning teams from Scrum to Kanban
• Has a Scrum-like board but with WIP limit on each column
• Board is persistent but can be reset as needed
• Team plans only when there’s need

51. Agile Resources
• http://agilemanifesto.org (The Agile Manifesto)
• https://scrumguides.org (Official Scrum Guide)
• Scrum and XP from the Trenches (A good, practical guide on Scrum)
• Essential Kanban Condensed (Kanban basics)
• Kanban and Scrum – Making the Most of Both (Difference b/w Scrum and Kanban)
• Is agile project management applicable to construction? (Research paper)

52. &A
Q