In 2001, the Agile Manifesto took the world by storm, and it changed how software is built forever. Also in 2001, OutSystems, another disruptive force in the world of traditional waterfall software development, was born. Not coincidentally, OutSystems has been using Agile Practices all along. However, because of the sheer speed at which we’re able to respond, we’ve had to come up with a few twists in our approach. We’re even putting it into a services delivery playbook. In our webinar, “By the (Play)Book: The Agile Practice at OutSystems,” Engagement Guild Master and Expert Nuno Fernandes will show you how OutSystems approaches Agile Development and makes sure nothing slips. In this session you will: - Learn roles and respective responsibilities. - Understand project phases with a clear focus on sprint development. - Discover how we approach the user story life cycle in particular. - See how a really solid structure, calendar and organization help maximize productivity. Webinar: https://www.outsystems.com/learn/courses/59/webinar-the-agile-practice-at-outsystems/ Free Online training: https://www.outsystems.com/learn/courses/ Follow us on Twitter http://www.twitter.com/OutSystemsDev Like us on Facebook http://www.Facebook.com/OutSystemsDev

1. By the (Play) Book
Agile Practice at OutSystems

2. Agenda
● Why Agile?
● The Team
● OutSystems Delivery Practice
○ Initiation
○ Sprint Development
○ Solution Release
2

3. 3
Reaching the full potential
Delivery practice
Development
Architecture
OutSystems platform
Keeping High Speed
delivering Maximum Value
with Quality

4. Why Agile?

5. We have come a long way...
5
www

6. Source: http://www.firstinsight.com
The normal Citizen has become a daily consumer of Technology
Agile was designed
for testing an idea
with key-users and
then building on top
of it driven directly by
the end user’s
perspective of Value
6
End Users now know best and demand to be heard

7. 7
Agile arose from the most
basic organic need
survival of the fittest
time to market
response to change
driven by value to end user

8. At the core
8
Individuals and interactions
over processes and tools
Customer collaboration
over contract negotiation
Working software
over comprehensive documentation
Responding to change
over following a plan
A community of professionals
over processes and tools
Well-crafted software
over comprehensive documentation
Productive partnerships
over contract negotiation
Steadily adding value
over following a plan
A community of professionals
over processes and tools
but closely following a well structured process
Well-crafted software
over comprehensive documentation
but work is centered around written and clear User Stories
Productive partnerships
over contract negotiation
but ensuring alignment when change comes
Steadily adding value
over following a plan
but there is a high-level plan and Sprint scope is sacred
Manifesto for Agile Software Development (2001)
Manifesto for Software Craftsmanship (2009)
Avoiding frAgile

9. 9
Requirements
Analysis
Implementation
Tests
Delivery
Waterfall
Agile
Source: http://blog.crisp.se/author/henrikkniberg
Plan
driven
Value
driven
Value comes first

10. 10
Working in an Agile way
Timebox (project budget)
Features that are used:
Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5 Sprint 6 Sprint 7
new features
always or often sometimes nice to have
Timebox (budget)
• Effort sum of all original features in the backlog
• Timebox is defined at start and is kept frozen
Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5 Sprint 6 Sprint 7
Assign to sprints
Prioritization criteria:
• Features that provide the most business value
• Dependencies between features
• Core first, details later
Features
for next
release
Handling feedback
• Minor changes are addressed in next sprint
• New features are added or not to backlog
according to priority - lesser valued items are
moved to next release

11. The Team

12. A community of professionals
12
Project
Manager
Delivery
Manager
Developers
IT
Manager
Business
Sponsor
Engagement
Manager
Key Users
Business
Analysts
OutSystems projects are heavily people-centric and collaborative
IT
Architect

13. OutSystems Delivery Practice

14. 14
No Agile
practice is

15. 15
Acceptance of
previous sprint
Supported by OS,
customer validates and
accepts delivered User
Stories
OutSystemsCustomer
2-3 week sprints 1-4 weeks
Project Delivery
Initiation Solution ReleaseSprint Development
Go Live
Initiation
1-2 weeks
. UAT
. Close roll-out
preparation
. Go Live at phase end
Accept
Shape
Build
Post
Production
. High level sprint
settlement
. Sprint 1 User
Stories definition
1 week
. Delivery kick-off
. Delivery practice
alignment
. DoR, DoD
. Vision doc
. App skeleton
ProjectSetup
. Monitoring
.Tuning
. Feedback
. Minor CR’s
Deliver current
sprint
User Story delivery
Shape next sprint
. New backlog
. Prioritize backlog
. Analyze and define
User Stories
Framework

16. OutSystems Delivery Practice
Initiation

17. 17
Initiation
Product
Vision
Company
Tactical Goals
Company
Strategic Goals

18. 18
Initiation
Always start with the end users
so that we may link back to the
Value Proposition at any point
in time
It is the user needs that will
derive all Backlog
Neverland
Neverland.

19. 19
Initiation
Modeling the main
Business Processes
breaks the ice and
kicks-off the discovery
process, returning a
most needed bird's
eye view
Mock-ups are key to
tackle the user’s
journey and how
they will interact
with the Product
ACME
ACME
UX and UI design
skills are essential

20. 20
Theme
Epics
High Level Stories
Initiation
The epic structure
helps organizing User
Stories and tracing
back to the identified
user needs
Create new offer
Create new offer
Define service
Change price on existing offer
Customer request
SDR request
Sales Rep request
Pre-Sales request
Transformation
Enablement
Delivery
Customer Success
Get Services
Get Service Types
Get Products
Get Territories

21. Initiation week: example
21
PM - Project Manager / BA - Business Analyst / KU - Key User key sessions
9:00
10:00
11:00
12:00
13:00
14:00
Welcome
Project kick-off
Talk by sponsors
Business context
As is vs To be biz process
Daily scrum
Top prio Epics and high
level stories
Top prio Epics and high
level stories
Daily scrum Daily scrum
Interaction with IT
Infra availability and
remote access
System integrations
Sprint working model
DoR, DoD, QA flow
First UI mockups
Non-functional reqs.
Sprint 1 planning
Wrap-up
Application architecture
Data reqs: migration / init.
IT Dev team ramp-up
Vision and roadmap
Visit user's work space
Day 2 Day 4 Day 5Day 3Day 1
Planning Business Tech / DevOps
15:00 : 18:00 A&D
A&D
A&D
Initial backlog / OS services
walkthrough
Release goals and scope
Analysis & Design
Needed customer roles are referred in each session
PM, BA, KU, IT Arch
All hands
PM, BA, Bus. Sponsor
PM, BA, KU, IT Arch
PM, BA, KU, IT Arch
PM, BA, KU, IT Arch
PM, IT Arch, IT Mng
PM, BA, KU, IT Arch
PM, BA
PM, BA, KU, IT Arch
PM, BA, KU, IT Arch
BA, KU
All hands
PM, IT Mng
PM, IT Arch, IT Mng
All hands
OS OS OS OS
All hands PM, BA, IT Arch PM, BA, IT Arch PM, BA, IT Arch

22. OutSystems Delivery Practice
Sprint Development

23. 23
Sprint Development
Shape
Build
User
Stories
Accept

24. 24
Sprint Development
As a <user role>
I can <activity>
so that <benefit>
Unfolds the user journey, step by step, using business language
States expected action/result, making it testable and fully verifiable
Unveils hidden assumptions, key for accurate effort estimate
Links to other US, ensuring connection of the parts
Depicts the expected user journey
Enriches with more context/scenario info if needed
COLLABORATION
Goal and business value of the User Story:

25. Definition of Ready
□ Is written down in the form: “As a <user role> I want to
<activity> so that <benefit>”
□ INVEST principles are met: Independent, Negotiable,
Valuable, Estimable, Small and Testable
□ Is mapped as a step in a business process diagram
□ Business context and value are clear
□ Is prioritized (for example based on MoSCoW)
□ Conversations have taken place to clarify US so everyone
(business, IT, Dev and QA teams) are aligned on what
exactly to build
□ Details are captured in acceptance criteria (functional and
nonfunctional)
□ Wireframes / mockups are drawn or reviewed for major US
□ Is validated by business
□ Test cases/scenarios are captured
□ Meaningful and comprehensive test data is available
□ Is estimated (at high level) and fits in a Sprint
Definition of Done
□ Code completed, adheres to IT guidelines and is published
on Dev environment
□ Unit tests completed successfully by developers and
confirmed by DM
□ Test cases for acceptance criteria executed with success
□ Reviewed and approved by EM
□ Usability (including performance) tests performed
□ Intermediate (preview) demo took place and a plan is in
place to address its feedback during stabilization, before
demo to business
25
Sprint Development

26. 26
Sprint Development
Sprint N+1Sprint N-1 Sprint N
* in case of multiple teams
** Customer availability is presented as reference
Sp. Plan
A&D
Implementation & Testing
Stabilizing
(N and N-x)
Analysis & Design
Delivery
/ Testing
Stabilizing (feedback
from N and N-x)
Design Delivery / Testing
Internal
Demo
Biz
Demo
Analysis / US
Definition
Sprint Plan
Int.
Demo
Biz
Demo
Acceptance
Testing
US Clarification
Sprint
Plan
US Clarification
Biz
Demo
Acceptance Testing
Tests
Plan
Int.
Demo
Sprint Plan
Int.
Demo
Biz
Demo
Biz
Demo
Sp. Plan
A&D
PO
Plan
Build Accept
PO
Plan
OutSystems
PM – Program Manager *
EM – Engagement Manager
DM – Delivery Manager
Dev – Developer
EXP – Expert (UX, Architect, Platform)
Customer
PM – Project / Program Manager
BS – Business Sponsor
IT – IT Manager / Architect
PO – Product Owner
BA – Business / Functional Analyst
KU – Key-User
QA – Tests / QA coordination Acceptance Testing
Shape
Write
backlog
Groom
backlog
Sprint
planning
Dev &
Test
Feedb
ack
Demo

27. 27
Sprint Development
N+1N-1 Sprint N
* in case of multiple teams
** Customer availability is presented as reference
Implementation & Testing
Analysis & Design Delivery / Testing
Design Delivery / Testing
Internal
Demo
Biz
Demo
Day 1 Day 2 Day 3 Day 4 Day 5 Day 6 Day 7 Day 8 Day 9 Day 10
Sprint Plan N+1 A&D N+1
Sprint Plan N+1
Design
N+1
Acceptance Testing
N-1
Analysis / US Definition N+1 Sprint Plan N+1
Internal
Demo
Business Demo
Acceptance Testing N-1
Sprint Plan
N+1
Internal
Demo
Acceptance Testing
US Refinement and Clarification Sprint Plan N+1
Internal
Demo
Biz
Demo
Product
Plan N+2
Biz
Demo
Acceptance Testing N-1
Sprint Plan
N+1
Tests Plan
N+1
Shape
Build
Accept
Biz
Demo
Product
Plan N+2
Stabilizing
(feedback from N and N-x)
Stabilizing
(feedback from N and N-x)
OutSystems
PM – Program Manager *
EM – Engagement Manager
DM – Delivery Manager
Dev – Developer
EXP – Expert (UX, Architect, Platform)
Customer
PM – Project / Program Manager
BS – Business Sponsor
IT – IT Manager / Architect
PO – Product Owner
BA – Business / Functional Analyst
KU – Key-User
QA – Tests / QA coordination

28. OutSystems Delivery Practice
Solution Release

29. 29
Solution Release
1-4 weeks **
Day 2 Day n-1Day 1 Day n...
Customer
Acceptance
Stabilization
UATUAT
UAT
(every other
day)
Roll-out plan
End-to-end testing / Minor changes / Defect fixing
Go Live
Change Mgmt
Release Mgmt

30. Links
OutSystems Project Delivery Playbook

31. Thank you!

32. www.outsystems.com
32