Vieno pilotinio projekto istorija

1. Situacija prieš Scrum ir Scrum pradžia

2. Grėbliai

3. Ar pasiekėm tikslus?

Situacija įmonėje. Struktūra

Situacija įmonėje. Darbas

Specialistams trūko:

Tobulėjimo

Vadovams reikėjo:

Kokybiškesnio rezultato

Laisvės, savarankiškumo

Bendro vaizdo, projekto vizijos matymo

Lankstumo

Didesnio gamybos efektyvumo

Pokytis: bottom-up ir top-down

Išrinktas pilotinis projektas

Didelis ir prioritetinis

Fiksuota kaina, fiksuotas terminas

Fiksuota apimtis epikų lygyje, bet nėra detalių reikalavimų

Kad trauktų dėmesį ir gautų resursų.

Nes visi projektai tokie.

Detalių reikalavimų nebuvimas atrodė gera priežastis taikyti būtent Scrumą.

Komandos surinkimasScrumu besidomintys savanoriaiKad sutiktų pasmerkti save rizikai ir nežinomybei

Pagrindinėsproblemos

1. Multitaskingas, supportas,nepastovūs prioritetai

“Tokiomis sąlygomis Scrum neįmanomas”

Sprendimai prieš pradedant pilotinį projektą:1. Supportas iki pietų, Scrum po pietų2. Pasiėmiau SM rolę ir prižadėjau užtikrinti komandai

geras sąlygas dirbti (po pietų)

To, aišku, dar neužteko.

1. Multitaskingas, supportas,nepastovūs prioritetai

Projekto metu – sprendimai įmonės lygyje:1. Projektų portfelis2. Prioritetizavimas3. Supporto atskyrimas nuo projektų

2. P.O. ir komanda

P.O. CEO

Sprendimai :1. komandos pastangos įtikti P.O.2. padaryti darbai laimi P.O. pasitikėjimąGeresnis sprendimas būtų savanoris P.O.

Trūko P.O. ir komandos bendradarbiavimo

“Scrum komanda pati viską padarys”

3. Didžiulė nedeliverinimo bėda

Identifikuotos priežastys:

1. Daug supporto sprinto viduryje.2. Optimistiškai vertindavom užduotis.3. Užtruko susitarti kas/kada/kaip “nušlifuoja” rezultatą.4. Stabdė rankinis testavimas.5. Per trumpas sprintas.6. Studento sindromas.7. Mažai bendravom su P.O. vidury sprinto

3. Didžiulė nedeliverinimo bėda

Deliverinti pradėjom tada, kai:

1. P.O. nuolat rodėm daromus darbus sprinto viduryje, klausinėti ar jau gerai ir ko dar trūksta.

4. Trintis tarp Scrum entuziastųir kitų įmonės darbuotojų

“Sekta!”

“Self-organizing: jie nevaldomi!”

Sprendimas: diskusijos, mokymai

“Jiems su projektu gerai, o mes turim daryti supportą”

“Jie sėdi kartu, o mes ne”

“Jie nebedaro mano darbų (supporto)”

“Jie ne dirba, o sėdi susirinkimuose”

“Žaidžia su lapukais”

“Daro Scrum pagal knygą”

“Mūsųnesupranta”

“Iš mūsų per daug reikalauja”

“Scrum’as čianeįmanomas”

“Mus mikrokontroliuoja”

“Mus verčiadarytiscrum-butt”“Mumis

netiki”

“Po projekto išardys mūsų komandą”

5. Sėdėjimas ne vienoje vietoje

6. Kompetencijų įvairovė

S.M./usability Dizainas HTML /CSS

Developeriai Testavimas

7. Netilpdavom lentoje

8. Ir kitos bėdutės...

• Susitarti, kam ką kada padaryti, kas “nušlifuos” rezultatą iki tinkamo rodyti klientui, kas “pavaduos” komandos narį, kurio nėra, ir t.t...

• Kaip elgtis, ką kalbėti ir ko nekalbėti susitikimuose, kaip greičiau priimti sprendimus...

• Kaip efektyviai “suklijuoti” kelių žmonių vienu metu daromą rezultatą...

Ar mums pavyko?

Ar projektas padarytas efektyviau už kitus?

Sunku pasakyti, nes:

• Projektas nepanašus į kitus

• Neaišku, kurią dalį laiko ir pastangų suvalgė Scrum proceso mokymasis

Ar greitėjo gamyba projekto metu?

Sunku pasakyti dėl:

• Nevientiso specialistų įsijungimo į projektą

• Pradžioje nedarytų vartotojo istorijų įvertinimų

Specialistams trūko:Tobulėjimo

Vadovams reikėjo:

Kokybiškesnio rezultato

Laisvės, savarankiškumo

Bendro vaizdo, projekto vizijos matymo

Lankstumo

Didesnio gamybos efektyvumo+/?++

+++

Bonusas: Išryškėjusios įmonės problemos

Ar pasiekti išsikelti tikslai?

Taip, mums pavyko

Ką padarėm gerai?

1. “Teisingas” žmonių rinkinys komandoje, dėmesys žmogiškoms problemoms, bendravimui (komandos viduje), ir t.t.

2. TIKSLAS (bendras visai komandai)

3. Retrospektyvos

4. Scrum-rollout komanda (su visų “sluoksnių” atstovais)

1. Visa įmonė eina komandų sudarymo linkme

2. Palaipsniui adaptuojami atskiri Scrum elementai

3. Scrum komanda toliau siekia savo TIKSLO

Kas toliau?