technical webinar: by the (play) book: the agile practice at outsystems
TRANSCRIPT
Agenda
● Why Agile?
● The Team
● OutSystems Delivery Practice
○ Initiation
○ Sprint Development
○ Solution Release
2
3
Reaching the full potential
Delivery practice
Development
Architecture
OutSystems platform
Keeping High Speed
delivering Maximum Value
with Quality
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
Agile arose from the most basic organic need
survival of the fittest
time to marketresponse to change
driven by value to end user
At the core
8
Individuals and interactionsover processes and tools
Customer collaborationover contract negotiation
Working softwareover comprehensive documentation
Responding to changeover following a plan
A community of professionalsover processes and tools
Well-crafted softwareover comprehensive documentation
Productive partnershipsover contract negotiation
Steadily adding valueover following a plan
A community of professionalsover processes and toolsbut closely following a well structured process
Well-crafted softwareover comprehensive documentationbut work is centered around written and clear User Stories
Productive partnershipsover contract negotiationbut ensuring alignment when change comes
Steadily adding valueover following a planbut 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
Requirements
Analysis
Implementation
Tests
Delivery
Waterfall
AgileSource: http://blog.crisp.se/author/henrikkniberg
Plan driven
Value driven
Value comes first
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 sprintsPrioritization criteria:• Features that provide the most business value• Dependencies between features• Core first, details later
Featuresfor 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
A community of professionals
12
ProjectManager
DeliveryManager
Developers
ITManager
BusinessSponsor
Engagement Manager
Key Users
Business Analysts
OutSystems projects are heavily people-centric and collaborative
ITArchitect
15
Acceptance of previous sprint
Supported by OS, customer validates and accepts delivered User
StoriesOut
Syst
ems
Cust
omer
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
Proj
ect S
etup
. 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
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
NeverlandNeverland.
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
Theme
Epics
High Level StoriesInitiation
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
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-offTalk by sponsors
Business contextAs 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 ITInfra availability and remote accessSystem integrations
Sprint working modelDoR, DoD, QA flow
First UI mockups
Non-functional reqs.
Sprint 1 planning
Wrap-up
Application architectureData 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&DA&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
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
COLL
ABO
RATI
ON
Goal and business value of the User Story:
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
Sprint Development
Sprint N+1Sprint N-1 Sprint N
* in case of multiple teams** Customer availability is presented as reference
Sp. PlanA&D
Implementation & Testing Stabilizing(N and N-x)
Analysis & Design Delivery/ Testing
Stabilizing (feedback from N and N-x)Design Delivery / Testing
Internal Demo
BizDemo
Analysis / US Definition Sprint Plan Int.
DemoBizDemo
Acceptance Testing
US Clarification Sprint Plan
US Clarification
BizDemo
Acceptance Testing
TestsPlan
Int. Demo
Sprint Plan Int. Demo
BizDemo
BizDemo
Sp. PlanA&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
Feedback
Demo
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
BizDemo
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 TestingN-1 Analysis / US Definition N+1 Sprint Plan N+1 Internal
Demo Business Demo
Acceptance Testing N-1 Sprint PlanN+1
Internal Demo Acceptance Testing
US Refinement and Clarification Sprint Plan N+1 Internal Demo
BizDemo
Product Plan N+2
BizDemo
Acceptance Testing N-1 Sprint PlanN+1
Tests PlanN+1
Shape
Build
Accept
BizDemo
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
29
Solution Release
1-4 weeks **Day 2 Day n-1Day 1 Day n...
Customer Acceptance
Stabilization
UATUATUAT
(every other day)
Roll-out plan
End-to-end testing / Minor changes / Defect fixing
Go LiveChange MgmtRelease Mgmt
Links
OutSystems Project Delivery Playbook