Agile and Scrum scalability:theory and practiceby Prykhnych Helen

About me Prykhnych HelenCo-founder & trainer @ E5

Agile Project manager @ BetlabIC Agile certified professional

> 10 years n IT

> 9 years as manager

Started as customer support agent and grew up to project manager

Last project – opening international outsourcing company’s office in Kyiv

Coordinate and inspire managers’ community – ITKaiZenClub in Kyiv

And you? ;)

SAFe: helicopter view

Project A

Why we need to scale?Complicated productІТ team up to 100 peopleFeatures development caused need of

architecture scalingRegular releases needed

Pre-conditionsDedicated Release Train Engineer (RTE)Architects teamStrong leadership team SCRUM teamsDedicated DevOps team

Portfolio level

Architectural features

Business features

Portfolio Backlog

Business Owners

Head of IT Development

Portfolio management

Strategic Themes

Release level

3 releases at the same time

Deliver Develop Plan

Deliver Develop Plan

Deliver Develop Plan

Test Pack UATS2Kanban + UAT S3

Pack & Deliver

Portfolio meeting EG1 EG2 Planning

Agile Release Train

S1

Release Train EngineerProduct Owner

Vision

ReleaseGoals Architectural Runway

Featureroadmap

Release scope

Release planning

Dependency matrix

Release delivery

Team level

2 weeks sprint

Team

Product Owner Scrum

master

Sprint backlog

Sprint Planning

Daily Stand up

Sprint DemoRetrospective

Epic grooming

Storygrooming

RTE Head of IT DevelopmentCPO

PO 1

PO 2

PO N

SM 1

SM 2

SM N

TL 1

TL 1

TL N

QA Lead

Sen QA 1

Sen QA 2

Sen QA N

DevOps

Arch 1

Arch 2

Arch N

TEAM 1

TEAM 2

TEAM N

Tech writer

Organization structure scaling

Best-practices

Improvement board

Topic Problem Profit

Demos Feedback from POs on1. Demo meetings bring value both to POs and external

guests2. We can collect feedback from all parties

Responsibilities of SMs

What we are responsible for and what we lack to execute it

1. Responsibilities are clear2. We have all power (and cookies) we need

CommitmentsScrum Teams are responsible for making and

delivering commitments. We do not have fully implemented "Getting things done"

mindset

motivated team to deliver realistic commitments, managed expectations for PO and business, managed opportunities to

deliver over commitment

How to process CI blockers

Too many open Blockers in the system, most of which are CI blockers

Clear understanding how to process CI blockers, descries number of Open Blockers in the system

Leadership knowledge exchange

Expectations from position

Pros and Cons

PlusScale 8+ Agile teams

Synchronization New features and architecture epics prioritization on portfolio level

Synchronization between the teams on release level

Releases Incremental releases every 4 sprints Ability to release quickly small patches

Risk management Risks and dependency management on different stages

Quality Quality control on all levels Technical debt management

Performance Focus for each release Full loading of development team

MinusRelease process ‒ Long Lead time

‒ Long deployment to Production

Quality ‒ Removing QA team from the sprint for regression testing

Performance ‒ Long grooming because of raw requirements

‒ Many not finished features because of priority changes

Process support ‒ Additional roles and rituals for SAFe process support

Project B

Why we need to scale?Complicated productІТ team grew up to 80-90 peopleFeatures development caused need of

architecture scalingFirst releases and transparency in team

work were needed

Pre-conditionsDedicated Delivery ManagerArchitectSCRUM teamsDedicated DevOps, UI/UX teams

Portfolio level

Architectural features

Business features

Portfolio Backlog

Strategic Themes

CTO

Architect

CEO

Clients

Product Managers

Release level

1 release at the same time

Develop Plan

Release Train Engineer

Product Owner

Vision

ReleaseGoals

Architectural Runway

Featureroadmap

Agile Release Train

Sprint 4PlanningPortfolio meeting Sprint 3Sprint 2Sprint 1 I&A

week

Dependency matrix

Team level

2 weeks sprint

Team

Product Owner Scrum

master

Sprint backlog

Sprint Planning

Daily Stand up

Sprint DemoRetrospective

Epic grooming

Storygrooming

Organization structure scaling

DM DevOpsArchitect

PM1

PO 1

PO 2

PO N

SM 1

SM 2

SM N

LD

Devs 1

LD, Dev N

QA Lead

QA 1

Sen QA 2

QA N

FE 1

FE 2

FE N

TEAM 1

TEAM 2

TEAM N

CTO FE Lead

PMN

UI/UX

Infra

Best-practices

Company retroOne common for all company problem

Brainstorm in teams

Results exchange and common action plan creation

1

2

3

Pros and Cons

PlusScale 7+ Agile teams

Synchronization New features and architecture epics prioritization with clients involvement

Synchronization between the teams on release level and cooperation

Transparency of teams’ work for C-level management and client

Risk management Risks and dependency management on different stages

Quality Quality control on all levels Technical debt management

Performance Focus for each release Full loading of development team

MinusPerformance ‒ Many not finished features

because of priority changes‒ Not mature enough product

and development teams

Process support ‒ Additional roles and rituals for SAFe process support

Product ‒ Hard to develop comprehensive product, but not customized for main client only solution

What do we need for successful scaling?

TOP 5 reasons from VersionOne

Is there any other way?

Statistics 2014 year by VersionOne

Useful linksSAFe (Scaled Agile Framework)

http://www.scaledagileframework.comDAD (Disciplined Agile Delivery)

https://disciplinedagiledelivery.wordpress.com/introduction-to-dad/ LeSS (Large-Scale Scrum)

http://less.works Version One Agile report

http://info.versionone.com/state-of-agile-development-survey-ninth.html

helen@e-5.com.ua E5Trainings E5Trainings E5 www.e-5.com.ua

Questions?