technical webinar: by the (play) book: the agile practice at outsystems

32
By the (Play) Book Agile Practice at OutSystems

Upload: outsystems

Post on 09-Apr-2017

71 views

Category:

Technology


0 download

TRANSCRIPT

By the (Play) BookAgile Practice at OutSystems

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

Why Agile?

We have come a long way...

5

www

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

The Team

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

OutSystems Delivery Practice

14

No Agile practice is

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

OutSystems Delivery Practice

Initiation

17

Initiation

Product Vision

Company Tactical Goals

Company Strategic Goals

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

OutSystems Delivery Practice

Sprint Development

23

Sprint Development

Shape

Build

User Stories

Accept

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

OutSystems Delivery Practice

Solution Release

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

Thank you!

www.outsystems.com32