Running Agile on a non-agile Environment

Nuno Caneco - 2017/01/12

BioNuno Caneco

Software Engineer for 13+ years

Scrum Practitioner since 2008

Scrum Master since 2009

Leading Software Projects since 2006

Motivation

Share the experience from executing a project using Agile under a Waterfall contract

How it startedFixed scope

Fixed delivery date(based on high level estimations)

Waterfall-based Project Management

Project Management FoundationsSchedule

Scope Budget

Quality

ResourcesRisk

Contract

Managed by Contractor (PM)

Agile & Contracts

Schedule

Scope Budget

Quality

ResourcesRisk

Fixed Contract:

Fixed Budget

Fixed Scope

Fixed Schedule

Waterfall Project Management

The Agile way:

Flexible Scope

Flexible Schedule

Flexible Budget

Internal Agile - The OpportunityUsing Agile would hopefully:

Improve the flexibility within the Team

Improve resource and time

management

Steady and frequent checkpoints

Small and frequent victories

Façades

SupplierCustomer

Sponsor

PM

Sponsor

PM / PO ScrumMaster

TTTeam

Waterfall AgileWaterfall & Agile

Combining Waterfall with Agile

Requirements

Design

Implementation

Verification

Waterfall Façade Agile Façade Activities

● Close high level specs with Customer● Epic Backlog● Initial Product Backlog

● Refine Product Backlog● Initial Mockups● Sprint 0 - project structure and first lines of code

● Sprints● Backlog Grooming● Internal QA & Demos

● Acceptance tests with customer● Bug fixes

RequirementsPhase

Preparing the Backlogs

Functional Specification● Modules

○ Features

User Acceptance Tests● High level UAT

(not that much detailed at this point)

Waterfall Façade Agile Façade

Epic Backlog

Product Backlog

Modules mapped to Epics

Features mapped to User Stories

UAT mapped to Acceptance Criteria

Epic Backlog PrioritizingPrioritize on Epics based on the following criteria:

1.Dependency to other Epics/Stories

Foundational epics go first

Epics that are dependencies to other epics go first

2.Risk & Impact

High risk + High Impact Epics are likely to go first

"Bread and butter" epics are likely to go last

At the End of Requirements PhaseThe Team had:

A Functional Specification approved by the customer

A high level UAT document approved by the customerand

A detailed and prioritized Epic Backlog

T-Shirt size estimation

A Product Backlog with:Detailed functional description

High level Acceptance Criteria

No User Story estimation

Implementation Phase

InvariantsSetup the Team

Front-end Engineers ; Back-end Engineers ; Lead Architect

2-week Sprints

Starting on Monday ; Ending on Friday (by agreement with the Team)

Recurring appointments on the agenda:

Sprint Planning

Daily meetings

Sprint Demo

Sprint Retrospective

Sprint Loop

Day 1 Day 2 Day 3 Day 4 Day 5 Day 6 Day 7 Day 8 Day 9 Day 10

Sprint Planning[Team + SM]

Backlog Grooming (Mid/long term)[SM + PO ; Team(optional)]

Mock-ups & User Store detail grooming [PO + SM]

Backlog Grooming (Sprint n+1)[Team + SM + PO]

Sprint Demo[Team + SM + PO + PM]

Sprint Retrospective[Team + SM]

Sprint n

Sprint Planning

Product Backlog Sprint BacklogStories are split into Tasks

Each Task:

Gets estimated in hours(Estimation > 12h → Split the task)

Is pre-assigned to a Team Member

Tax Tasks:

Backlog Grooming

Daily meetings

Sprint Demos

(...)

● Story ID● Description● Estimation [Story Points]● Mock ups

● Task ID● Story ID● Task Type● Description● Assignee● Estimation [h]● Time tracking

Definition of DoneExamples:

Code on Source Control must compile and run by hitting F5

Tests must be implemented and passing

Database project must be updated

And, then by Sprint #4...

We need a working BETA version in 1 month!

Time to Adapt!Identify the user stories that become critical for the BETA

Enter Kanban mode for 2 sprints to:a. Finish the features

b. Install the system @ PROD

Sprint #1 Sprint #2 Sprint #3 Sprint #4 Sprint #5 Sprint #6 Sprint #7 Sprint #8 (...)

Scrum Scrum Scrum Scrum Scrum Kanban Kanban Scrum (...)

BETA went well

QA & Testing

Adding a QA to the TeamAt some point, we decided to bring in a QA into the team:

Iterate towards the final UAT document

Test the outcome of Previous Sprint according to UAT document

Report bugs

QA loop

Sprint n

QA: Test fixed bugs

QA: Run UAT tests on new storiesTeam: Fix issues reported by QA (within saved capacity)

QA: Iterate on UAT document

The QA Loop was integrated with the Team Loop

It was nice

The bugs were found and fixed sooner!

Show me some numbers!

Some numbers

17x 2-week Sprints

5 software engineers (backend and frontend)

1 QA (non-permanent)

~210.000 lines of code

From which 37.000 are tests (~12%)

4 software applications + 1 common library

Velocity, capacity and time

Lessons learned

ProsGuided and steady workflow

Regular sense of completion at the end of each Sprint

Quickly respond to change

Pre-align epics to Sprints

Waterfall Status Reports became really easy

Just use the data from Sprint Demos

Deallocations and inefficiencies become visible

Improved the Team buy-in on the Project

ConsA bit of Management overhead

Map Scrum <--> Waterfall

Higher allocation of QA Team MembersEarly allocation to the Project

Lessons LearnedIt's easier to run Internal Scrum if the Management buys the strategy

And our Management did support this strategy

Using Kanban for stability Sprints

Improved the flexibility to fix issues and implement quick-but-needed features

If properly aligned, the Waterfall artifacts can be mapped to/from Agile artifacts with minimal effort

Technical Specification → Epic Backlog and Product Backlog

Sprint Demos & Sprint Backlog → Status Reports

Acceptance Criteria → User Acceptance Test

But most importantAlways remember that the customer did NOT buy Agile

Keep the

Façade Keep the fixed scope and time to the customer

Allow some internal

flexibility

Thank you