www.luxoft.com

Using Agile Methods

for Innovative Products Development

Luxoft Agile Practice Webinar

Prepared for SPIBA

7 Jun 2017

www.luxoft.com

Sergey Prokhorenko

Agile coach, head of Luxoft Agile Practice

sprokhorenko@luxoft.com

sergeyprokhorenko

www.luxoft.com

Session Plan

Late-learning strategies and when they don’t work

Design as a knowledge acquisition

Agile culture in a corporate environment

Team-based organization and other Agile principles

Agile contracts and pricing methods

Materials for further reading and watching

Q/A

www.luxoft.com

Typical Waterfall Model Challenges

vs.

www.luxoft.com

Design as a Knowledge Acquisition (Late Learning)

Never45%

Rarely19%

Sometimes16%

Often13%

Always7%

Actual Use of Requested Features

Source: The CHAOS Manifesto

The Standish Group, 2011

www.luxoft.com

Use Prototypes for Early Learning

www.luxoft.com

Origins of Scrum

www.luxoft.com

Prototyping & Reseach Spikes

www.luxoft.com

Self-Organizing Project Teams

Theory X Theory Y

www.luxoft.com

Prioritize Backlog to Get MVP

www.luxoft.com

Top Challenges Addressed by Agile Approach

0% 25% 50% 75% 100%

Improve project visibilty

Increase productivity

Enhance ability to managechanging priorities

Accelerate product delivery

Reasons for Adopting Agile1. PAYING FOR THE WRONG THINGS

60% of money are spent on features

which are never or rarely used by real users

2. ALWAYS LATE WITH THE THINGS WE REALLY NEED

Engineers tend to reinventing the wheel and focusing on interesting

engineering stuff instead of business priorities

3. TOO EXPENSIVE TO MAKE EVEN LITTLE CHANGES

Long change cycles due to complicated change management

procedures which consumes time and money

4. DIFFICULT TO UNDERSTAND WHERE WE ARE RIGHT NOW

Client is overburden with different reports

but have no clue of real progress in terms of working features Source: VersionOne® 11th State of Agile Report, 2017

www.luxoft.com

18

pages

289

pagesvs

Agile in a “Friendly” Environment is Easy

TEA

M

SCRUM

MASTER

PRODUCT

OWNER

Sprint

Backlog

(Tasks)

Product Backlog

Refinement

5-10% of Sprint

Potentially

Shippable

Product Increment

Sprint

Planning

Part 1

(What?)

2-4h

1 Day

2-4 weeks

Sprint

Sprint

Review

2-4h

Sprint

Retrospective

1,5-3h

Daily Scrum

15 min

Product

Backlog

(Features)

Sprint

Planning

Part 2

(How?)

2-4h

www.luxoft.com

Perception of Agile as a Silver Bullet

www.luxoft.com

Perception of Agile as a Silver Bullet – Reasons

Source: Developing Modern Applications With Agile Outsourcing, Forrester Research, 2014

Addressing Agile AD&M challenges…

Doing right things for business

Change for free

Clear progress

Cross-functional teams

…while following non-Agile SVM restrictions*

Greater vendor accountability

Fixed scope

Ring-fenced change

Shared resource models

www.luxoft.com

Agile Is About IT Training and Coaching

www.luxoft.com

What “Good Scrum” Looks Like (Enterprise View)

Agile Practices

- Sprint planning meeting

- Daily stand up

- Backlog refinement

- Sprint retrospective

- Sprint review / demo

Agile technical design – ensuring that the short cycle approach does not

lead to no overarching design, and equally that there is not a large

waterfall style design process which becomes a blocker in itself

Following a Quality Scrum Process (avoid a "Cargo Cult") – effectively

breaking down large tasks, writing good quality stories, running the scrum

board, running sprints effectively, understanding the drivers behind why

we're following the Agile approach (i.e. efficiency and responding to

change)

A common understanding of the Agile Practices

Proof of continuous improvement (e.g. automated testing)

High team morale

Self organising & managing – the coach can be extracted and the team

keeps functioning

Understanding the concept of "done", and not being satisfied until that is

achieved

Strong focus on testable software, and a clear trend on the amount of

testing done automatically and within the Sprint

Strong working partnership with Product Owner to maximise business

value

Changed behaviour and mind-set to lean / Agile – not a "Cargo Cult" simply

emptily following practices

Avoidance of anti patterns

Desire to track and understand team velocity, and to use this in the

planning of future Sprints to manage Product Owner expectation, and to

show continuous improvement

Desire to share success stories (and failures) with other teams as part of a

desire to continuously improve the entire organisation

www.luxoft.com

No Changes in Organizational Structure

Functional team managers (development managers, QA leads, BA leads etc)

Product owners from IT (BA) rather than business

PM becoming Scrum Master but still responsible for delivery

Architects

Dedicated release engineers

Development and QA testing outsourced to different vendors

www.luxoft.com

Rigid Contracting

www.luxoft.com

Common Pitfalls

Using traditional sourcing

partners for Agile development

Lack of Agile culture at both

sides

One-off training approach

Product Owners from IT, rather

than business

No changes in organizational

structure

Rigid contracting

Best Practices for Agile Outsourcing

Define Agile transformation strategy

Make process practices explicit for everyone at

client and vendor sides

Appoint great Product Owners and ensure

collaboration with vendor teams

Pay attention to requirements pipeline and long-

term planning

Focus on creating mutual trust

Contracting framework to support flexible scope

Practice constant coaching and training of Agile

teams

www.luxoft.com

Enabling Requirements Flow in Distributed Scrum

Knowledge and communication of

short- and mid-term project backlog

Deep understanding of

requirements refined to

user story level

Able to respond team’s questions

and requests promptly

Assuring team’s understanding of

requirements for upcoming sprints

Participation in product backlog

refinement sessions before

development start

Focused on business goals

on high level

Focused on early delivery of user

stories from sprint scope in

priority order

Product Owner(could be replaced by stakeholders

steering committee)

Team(developers, testers,

designers etc.)

Proxy Product

Owner(role could be handled

by business analyst)

Requests prioritization

Understanding and communication

of mid- and long-term project goals

Not necessarily deep subject matter

expertise

Definition of sprint goal and

acceptance of result

www.luxoft.com

Comprehensive Planning Framework

PRODUCT

OWNER

Developers,

QAs etc.

CROSS-

FUNCTIONAL TEAM

Proxy

PO

Team

preplannin

g

pPO + PO

Sprint

backlog

drafting

Sprint

planningProduct

Backlog

refinement

Product

Backlog

refinement

Team + pPO Team + pPO +

POTeam + pPO +

PO

Team + pPO +

PO

Sprint (-1) – analysis and preparation go in paralel with

development

Sync product vision

Elaborate mid-term goals

Create/update user personas

Map user stories

Review velocity

Set release goals

Prioritize & estimate release backlog

Create sprint backlog

Split backlog into small tasks

Review progress

Select next tasks

Plan actions

Product discovery

(3-6 months)

Release planning

(2-8 weeks)

Sprint planning

(1-2 weeks)

Daily standup

(daily)

www.luxoft.com

Agile Process Scaling (LeSS, Nexus, SAFe 4.0)

Setup of disciplined Agile delivery on a team

level (Scrum/Kanban/XP)

Product discovery process on feature

stream and product levels, seamless

stitching with team-level delivery (Agile

Release Trains)

Scaling to product/program portfolio level

with strategic planning/roadmapping, rich

visualization instruments and collaboration

practices

Best practices from LeSS, Nexus, SAFe 4.0

and other scaled Agile frameworks

www.luxoft.com

Common Engagement Models

Outstaffing (“Cost+”)

BOT (Build-Operate-Transfer)

Team Extension

Managed Delivery

www.luxoft.com

Top Agile Contracting Frameworks @ Luxoft

T&M

- “Plain vanilla” T&M

- T&M NTE (not-to-exceed)

- Good for initial stages

(build trust)

- Measurement unit: man-

day

Fixed Capacity (Agile

Pod)

- T&M-like pricing, but

packaged for a team

- Vendor responsibility for

strong team building

- Good for long-term

projects with sustainable

requirements flow

- Measurement unit: team-

sprint (for fully functional

team)

FP per Work Unit

- Output-based pricing

- Vendor margin is based on

performance

- Best risk management

approach for client

- Measurement unit: story

point (aligned with pre-

agreed Definition of Done)

www.luxoft.com

T&M and T&M NTE

Pros

• Least formal contracting framework

• Easy scaling

• Good for team extension model

Cons

• Vendor is not accountable for result

• Uncontrollable spending (for standard T&M)

• Low-level engagement with lower margin

www.luxoft.com

Fixed Capacity (Agile Pods)

Fixed price per team

- Minimum team setup is defined upfront (e.g. 3x senior Java developers, 1x QA/BA, 1x BA/QA – one of them plays

Scrum Master role)

- Team minimal target velocity is agreed in SoW

- Definition of Ready and Definition of Done is contracted (if needed)

Billing for every complete cross-functional team (T&M rates + extra margin to cover team forming

stage and attrition risks) per sprint or several sprints

If team becomes dysfunctional due to attrition (falls under minimal target velocity), vendor is responsible

for hiring and training new people, otherwise team isn’t billed

Not fully managed delivery, as delivery risks stay on the client side

www.luxoft.com

Fixed Price per Work Unit (Story Point)

Definition of “done” and acceptance scenarios agreed

before development

Features are demonstrated to customer only

if 100% done and meet acceptance criteria

Indicative sizes of user stories (in Story Points) are

included into SoW

Features are billed after UAT closed

Monthly payments based on estimates of features accepted

within previous billing period

Client is responsible for providing backlog according to

Definition of Ready

Feature A Feature B Feature C

…

Feature Z

Sprint planning

Feature A (100% done)

Prioritized

backlog

Fixed sprint duration (2 weeks)

Demo (100% done features only)

Feature A

Feature B(100% done)

Feature C (85% done)

Feature B

UAT (1-2 weeks)

Feature A

Feature B

Issues and change requests are

added to product backlog

DoR DoD

www.luxoft.com

Forming Initial Backlog – Product Discovery Workshop

Identification of key user roles

Story mapping and identification

of key functional scenarios

Forming of product backlog based on user story

maps

Relative sizing of user stories in a backlog

Identification of acceptance criteria

for top priority stories

Predicting team velocity and planning

of first development sprint

Release roadmap

www.luxoft.com

Luxoft Agile PracticeIN NUMBERS:

2004 Year of establishment

20+ Agile coaches (US, Europe)

70+ clients

250+ ongoing projects

600+ CSM/PSM/ICP

3000+ Agile practitioners

www.luxoft.com

Our Services

Agile coaching and consulting

Certified ICAgile and Scrum.org trainings

Custom trainings, workshops and webinars

Dedicated Scrum Masters outstaffing

Process audits and gap analysis

Agile/Lean organizational transformation

Agile process and environment setup

Engineering practices implementation

www.luxoft.com

More Information

agile@luxoft.com

http://blog.luxoft.com/agile

https://www.facebook.com/LuxoftAgilePractice/

https://www.youtube.com/c/LuxoftAgilePractice

My personal contacts:

sprokhorenko@luxoft.com

https://www.linkedin.com/in/sergeyprokhorenko

www.luxoft.com

THANK YOU