Top Banner
Agile Software Development vs. Big Projects Jakub Dziwisz Karolina Stępień 1 technology
20

Lekkie metodyki kontra duże projekty

Dec 07, 2014

Download

Technology

"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.
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Page 1: Lekkie metodyki kontra duże projekty

Agile Software Development vs. Big Projects

Jakub Dziwisz

Karolina Stępień

1 technology

Page 2: Lekkie metodyki kontra duże projekty

Agenda

Story of TripCase Platform

When the fun began

Agile challenges – cases

Where are we now

Where do you go

technology confidential 2

Page 3: Lekkie metodyki kontra duże projekty

Everything started 18 months ago

technology 3

Page 4: Lekkie metodyki kontra duże projekty

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

Page 5: Lekkie metodyki kontra duże projekty

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

technology confidential 5

Page 6: Lekkie metodyki kontra duże projekty

We started having serious problems...

Delays

Integration issuses, bugs

Lack of visibility

Miscommunication

technology confidential 6

Page 7: Lekkie metodyki kontra duże projekty

Problems and solutions

technology 7

Page 8: Lekkie metodyki kontra duże projekty

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

Page 9: Lekkie metodyki kontra duże projekty

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

Page 10: Lekkie metodyki kontra duże projekty

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

Page 11: Lekkie metodyki kontra duże projekty

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

Page 12: Lekkie metodyki kontra duże projekty

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

Page 13: Lekkie metodyki kontra duże projekty

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

Page 14: Lekkie metodyki kontra duże projekty

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

Page 15: Lekkie metodyki kontra duże projekty

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

Page 16: Lekkie metodyki kontra duże projekty

Where are we now?

technology 16

Page 17: Lekkie metodyki kontra duże projekty

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

Page 18: Lekkie metodyki kontra duże projekty

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

Page 19: Lekkie metodyki kontra duże projekty

Still learning & improving

Communication, communication, communication...

„Love” sphaghetti!

Integration

technology confidential 20

Page 20: Lekkie metodyki kontra duże projekty

Thank you!

[email protected]

Twitter: @dziwisz

technology 21