Agile Connect Lisbon - meetup #1 (https://www.meetup.com/Agile-Connect-Lisbon/events/236339361/) Talk "Running Scrum on a non-Agile environment - Tales from a past experience" By Nuno Caneco (Senior Software Engineer @ Talkdesk - https://www.linkedin.com/in/nunocaneco) Description: Running Scrum can be hard, sometimes. And it becomes harder when the organization that is sponsoring or executing the project is not oriented towards Agile principles and practices. This talk is about sharing some techniques (and lessons learned) that allowed the Team to leverage an Agile project execution model with a Waterfall commercial and project management models.

1. Running Agile on a non-agile
Environment
Nuno Caneco - 2017/01/12

2. Bio
Nuno Caneco
● Software Engineer for 13+ years
● Scrum Practitioner since 2008
● Scrum Master since 2009
● Leading Software Projects since 2006

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

4. How it started
● Fixed scope
● Fixed delivery date
(based on high level estimations)
● Waterfall-based Project
Management

5. Project Management Foundations
Schedule
Scope Budget
Quality
ResourcesRisk
Contract
Managed by Contractor (PM)

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

7. Internal Agile - The Opportunity
Using Agile would hopefully:
● Improve the flexibility within the
Team
● Improve resource and time
management
● Steady and frequent checkpoints
● Small and frequent victories

8. Façades
SupplierCustomer
Sponsor
PM
Sponsor
PM / PO ScrumMaster
TTTeam
Waterfall AgileWaterfall & Agile

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

10. Requirements
Phase

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

12. Epic Backlog Prioritizing
Prioritize 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

13. At the End of Requirements Phase
The Team had:
● A Functional Specification approved by the customer
● A high level UAT document approved by the customer
and
● 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

14. Implementation
Phase

15. Invariants
● Setup 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

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

17. Sprint Planning
Product Backlog Sprint Backlog
● Stories 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

18. Definition of Done
Examples:
● Code on Source Control must compile and run by hitting F5
● Tests must be implemented and passing
● Database project must be updated

19. And, then by Sprint #4...
We need a working
BETA version in 1
month!

20. 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 (...)

21. BETA went well

22. QA & Testing

23. Adding a QA to the Team
At 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

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

25. It was nice
The bugs were found and
fixed sooner!

26. Show me some numbers!

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

28. Velocity, capacity and time

29. Lessons learned

30. Pros
● Guided 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

31. Cons
● A bit of Management overhead
○ Map Scrum <--> Waterfall
● Higher allocation of QA Team Members
○ Early allocation to the Project

32. Lessons Learned
● It'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

33. But most important
Always 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

34. Thank you