Lekkie metodyki kontra duże projekty

Preview:

DESCRIPTION

"Wszyscy" wiedzą (a amerykańscy naukowcy nawet udowodnili), że lekkie metodyki dobrze sprawdzają się w małych zespołach. Ale co w przypadku dużych projektów lub programów - czy tam też uzasadnione jest użycie Agile'a/Scruma/Kanbana/XP? Platforma TripCase od kilkunastu miesięcy rozwijana jest przez zespół liczący blisko 100 osób. Proces, którego używa zespół, cały czas ewoluuje i bezsprzecznie oparty jest na lekkich metodykach. W trakcie prezentacji autorzy podzielą się swoimi doświadczeniami związanymi z kształtowaniem "lekkiego" procesu, który działałby dla tak licznego zespołu.

Citation preview

Agile Software Development vs. Big Projects

Jakub Dziwisz

Karolina Stępień

1 technology

Agenda

Story of TripCase Platform

When the fun began

Agile challenges – cases

Where are we now

Where do you go

technology confidential 2

Everything started 18 months ago

technology 3

What are we working on?

TripCase Platform - ca. 100 team members delivering one product

Common interface (one!), visible to end user

Same vision and strategy

technology 4

I think frankly when it comes to chaos you ain't seen nothing yet

technology confidential 5

We started having serious problems...

Delays

Integration issuses, bugs

Lack of visibility

Miscommunication

technology confidential 6

Problems and solutions

technology 7

Common backlog

Situation – Every team had their own backlog, prioritized list of

projects – at one point in time we could have multiple projects having the highest priority

– Delivery dates for projects were discussed separately across teams

Problem – Pretty often teams had conflicting priorities, yet projects

required collaboration (not competition)

Solution – Keep one backlog for all teams – this way we all know what

is the most important project at any point in time

technology confidential 8

Pre-planning or just aligning priorities?

Situation:

– Pre-planning meetings were separate for each team

– We have discussed (separate) priorities of projects

Real problem:

– Projects’ priorities didn't exactly define scope of iteration (which stories are the most important for business?)

– Priorities were conflicting even though required collaboration between teams

Solution: joint pre-planning meeting – increase visibility, address dependencies

technology confidential 9

Distributed team

Situation

– Integration of components took weeks due to a short communication window between KRK and DFW

Problem

– Knowledge about a component was available only in one location, a tiny bug meant a wasted day

Solution

– We need a team present both in KRK and DFW

– Team members need to be up to speed with all projects going on in their area

technology confidential 10

Share epics across teams

Situation:

– We had duplicated stories within teams

– Code met acceptance criteria, but E2E solution was incomplete or didn’t meet business requirements

– We have missed dependencies and were unable to deliver on time

Real problem: we were lacking bigger picture, enough visibility and communication

Solution: teams started working on the same epics (aka goal) split into stories

technology 11

Plan communication

Situation – One project, 2-3 sets of requirements...

Problem – Changes to the project’s scope, requirements, dates... any

changes... not always communicated broadly enough

Solution – Plan communication about projects in general and each

single project

– Document requirements, document changes in requirements

– Remember to invite the right people to meetings and copy the right people in emails (not everyone!)

technology 12

Breaking down silos

Situation:

– Although components were tested well and worked perfectly, E2E solution did not

– We made assumptions which were incorrect

– No one wanted to take ownership for E2E solution

Real problem:

– We used to work and think as single, isolated team and we still did

Solution:

– Scheduled integration as soon as possible

(same iteration across teams)

– Enhance communication

– Doesn’t work on your side as long as it doesn’t E2E

technology 13

Unify common practices

Situation

– Each team used their own flavor of Agile

Problem

– We used same words to say different things

– A team expected from another artifacts that weren’t going to be produced

Solution

– Unify dates for „shared” milestones

– Unify implementation of practices that influence other teams

technology 14

Architecture

Situation:

– Similar business logic, data etc. was duplicated in all projects - designing new solutions was truly cumbersome, technical debt growing

Problem:

– From 3 separate projects we jumped into one platform without simplifying architecture, consolidating components – “spaghetti” architecture

Solution:

– Designing solution keep in mind longer term vision of architecture

– Refactoring architecture whenever possible

technology confidential 15

Where are we now?

technology 16

Phase Discovery Elaboration Development System Test Release

Process at the high level

Product Responsibilities Feature

Description

Detailed Requirements &

Budget

Project Approval & Requirements

Clarification

Acceptance & Release Notes

Customer Communication

Development Responsibilities

ROM

Project Start

•Story Backlog

•Architecture

•Dependencies

•Schedule

•Effort / Cost

Coding Start

•Detailed Stories

•Working Code

Integrate Feature End-to-

End & Demonstration

Deployed Product

BRD Review

Kickoff Checkpoint Code

Complete Go /

No-Go

Release Process Overview

Translations Sent

Draft Release Notes

INT Go/No Go

Code Freeze / Branch Cut

INT Implement

Export Defects

Publish Release Notes

System Test Start

Load Testing

Sys Owner Review

Translation Verification

CERT Go/No Go

CERT CR Prepared

CERT Implement

Security Tests

PROD CR

PROD Go/No Go

PROD Implement

Still learning & improving

Communication, communication, communication...

„Love” sphaghetti!

Integration

technology confidential 20

Thank you!

jakub.dziwisz@sabre.com

Twitter: @dziwisz

technology 21

Recommended