Introduction to Agile

Scrum, Kanban, and everything in between

Pravin Singh

The world before Agile

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

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.

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.

The Iron Triangle - Waterfall

Scope

Schedule Cost

Plan Driven

The Iron Triangle - Agile

Scope

Schedule Cost

Value Driven

Delivery

Verification

Work Breakdown - Agile

Requirements

Design

ImplementationF

eatu

re 1

Fea

ture

2

Fea

ture

3

Fea

ture

4

Fea

ture

5

Fea

ture

6

Fea

ture

7

Fea

ture

8

Painting the Mona Lisa - Waterfall

Painting the Mona Lisa - Agile

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

The Agile Manifesto

We are uncovering better ways of developingsoftware by doing it and helping others do it.

Through this work we have come to value:

Individuals and interactions over processes and toolsWorking software over comprehensive documentation

Customer collaboration over contract negotiationResponding to change over following a plan

That is, while there is value in the items onthe right, we value the items on the left more.

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.

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.

Flavors of Agile

AgileScrum

Kanban

XP

FDD

Crystal

When Agile works best

• Unclear/evolving requirements

• Changing priorities

• Customer availability

• Collocated team

• Flexible funding (like Time & Material contracts)

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

Game Time☺All talk and no play

makes session a dull affair

Scrum

Scrum in a nutshell

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

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

Scrum Roles

Scrum Master

• A servant-leader for the team

• Removes impediments

• Facilitates Scrum events

• Helps Product Owner maintain the backlog

• Coaches and guides

Scrum Events

• The Sprint

• Sprint Planning

• Daily Scrum (Standup)

• Sprint Review (Demo)

• Retrospective

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

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

Scrum Board

Backlog Conceptual Design

Schematic Design

ConstructionDocs

Done

User Story 1

User Story 2

User Story 3

User Story 4

Task 4Task 2

Task 3Task 1

Task 5Task 4

Task 3 Task 2Task 1

Task 4 Task 3 Task 2Task 1

Task 2 Task 3Task 1

Burndown Chart

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.

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

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

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

…and “SMART” Tasks

• S – Specific

• M – Measurable

• A – Achievable

• R – Relevant

• T – Time-boxed

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

Scrum Tools

• Rally (now CA Agile Central)

• IceScrum

• Taiga

• YouTrack

• Hansoft

• JIRA

Game Time☺All talk and no play

makes session a dull affair

Kanban

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.

3 simple rules

• Visualize Workflow

• Limit WIP (Work in Progress)

• Manage Flow

Why Kanban

• Sometimes time-boxing doesn’t work

• Easy integration with other processes

• Does not mandate cross-functional team

• Minimal entry barrier

Creating a Kanban board

Backlog In Progress Done

Creating a Kanban board

Backlog In Progress4

Done

Creating a Kanban board

Backlog Ready2

In Progress4

Done

Creating a Kanban board

Backlog Ready

2

Conceptual Design

1

Schematic Design

2

ConstructionDocs

3

Done

Creating a Kanban board

Backlog Ready

2

Conceptual Design

1

Schematic Design

2

ConstructionDocs

3 Done

Doing Done Doing DoneDoing Done

Creating a Kanban board

Backlog Ready

2

Conceptual Design

1

Schematic Design

2

ConstructionDocs

3 Done

Doing Done Doing DoneDoing Done Swim lanes based on Priority/

Due date/ Nature of

work

Cumulative Flow Diagram

Kanban Tools

• LeanKit

• YouTrack

• Hansoft

• Rally (now CA Agile Central)

• JIRA

Scrumban

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

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)

&AQ