4Developers 2015: Twój zespół dobrze się bawi czy dobrze się bawi pracując? - Adam Michalczyk

Post on 06-Aug-2015

102 views 0 download

Transcript of 4Developers 2015: Twój zespół dobrze się bawi czy dobrze się bawi pracując? - Adam Michalczyk

Twój zespół dobrze się bawi, czy dobrze się bawi pracując?

Adam Michalczyk

Adam Michalczyk

Developer, Manager, SM, Lider 7 lat @ allegro

@zajonchek

zespoły

• dlaczego?

• tradycyjne

• które się nie bawią

• które się bawią

• które się bawią, pracując

“zabawa” i “zespół”

Dan Pink

• autonomia (autonomy)

• mistrzostwo (mastery)

• cel (purpose)

struktura merytoryczna

silosy budują soft

project management

1000 bugów

robienie roboty

relacje są mało istotne bo chodzi o dowiezienie

rozwój kompetencji twardych

łatanie kompetencji miękkich

przekazania pracy

niska jakość gratis

niska jakość gratis

Ludzi i interakcje ponad procesy i narzędzia. Działające oprogramowanie ponad obszerną dokumentację.

Współpracę z klientem ponad formalne ustalenia. Reagowanie na zmiany ponad podążanie za planem.

openness courage respect focus

commitment

fakty ponad obietnice zaufanie

empiryzm informacja zwrotna

…się nie bawią

mechanika

produkt zamiast projektu

Owner mówi “co”

zespół mówi ile i jak

wypełniamy role

management obwieszcza zmianę

jest wolniej, będzie szybciej…

jest wolniej, będzie szybciej…

scrum buts

historyjki gantta

zespół wybiera wymiar kary

zespół powoli staje się interdyscyplinarny

czy kultura się zmieniła?

budujemy wewnętrzną spójność

zaczynamy dobrze się bawić

trochę odpowiedzialności

trochę mistrzostwa

trochę celu

transparencja, DoD, review

zaufanie do PO, mamy wspólnego wroga

zespół mechanicznie adżajlowy

zespół … scrumowy

czy Twój zespół celebruje to czego się nauczył, czy koniec sprintu?

jak zespół nauczył mnie leadershipu?

zaufanie informacja zwrotna

rozwój

właściwe metody we właściwym czasie

odwaga stawiania wyzwań

ramy w rozwoju

wielokrotnie powtarzany przekaz

samoorganizacja to nie anarchia i trzeba się jej

nauczyć

w Scrumie każda rola jest rolą zarządczą.

sami jesteśmy odpowiedzialni za

autonomy, mastery i purpose.

leadership to nie management management jest o innych

leadership jest o Tobie