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
[email protected] E5Trainings E5Trainings E5 www.e-5.com.ua
Questions?