Hvorfor smidig feiler - eller?

James Shore har skrevet en artikkel om hvorfor mange smidige team sliter. Han spår at det at mange team mislykkes på tross av at de (hevder at de) jobber smidig, til slutt vil føre til at folk vender ryggen til smidig. Smidig får skylda for problemene, mens det egentlig er utførelsen som er feil. Akkurat det har jo Simon Johnson en litt annen vinkling på. Men det er en interessant artikkel, les den gjerne, der særlig Scrum får mye av skylda for at det er så mange som hevder de driver smidig uten å egentlig gjøre det.

På en måte føler jeg kritikken mot de som forsøker å drive smidig, men ikke får det til 100% blir litt lettvint. For eksempel: "De sier de driver smidig, men de er jo ikke samlokaliserte, så klart at de ikke driver ordentlig smidig, og klart at de vil slite". Ikke alle team har muligheten til å være samlokaliserte. Ikke alle team har en sterk produkteier som er nok tilgjengelig. Ikke alle team behersker alle de tekniske teknikkene i XP. Og så videre.

Det er egentlig ganske selvfølgelig at et team som har alle forutsetninger på plass, slik de er beskrevet i XP eller i James Shore's veldig gode bok om smidig utvikling, vil lykkes. Utfordringen for de aller fleste er å begripe hva som er det ideelle, hvor man avviker fra det ideelle, og så finne ut hva man kan gjøre for å nærme seg det ideelle best mulig. Og siden de fleste av oss har mye å vinne på flere områder gjelder det også å finne ut hva som vil gi mest verdi å endre, og så angripe det området først.

Det må nevnes at jeg synes The Art of Agile Development av James Shore er et ypperlig verktøy for nettopp å forbedre prosessene sine litt etter litt. Og det finnes mange andre gode kilder til kunnskap og inspirasjon i forbindelse med smidig. Det viktigste er at vi hele tiden forsøker å forbedre oss. Hvis vi noen gang når den perfekte prosess er det 100% sikkert en illusjon.

En programmerers bekjennelser

Er du som meg, gremmer du deg av og til over synder du har begått i løpet av karrieren - da du ikke visste bedre eller kanskje handlet mot bedre vitende.

Det er flere av oss - les Jeremy Millers bekjennelser - mens du ler gjenkjennende!

Program manager

Joel Spolsky skriver på bloggen sin om rollen "Program manager", en rolle som var ganske ukjent for meg. Det nærmeste vi har vært, har vært prosjekter der det har deltatt interaksjonsdesignere som har laget funksjonelle spesifikasjoner som utviklerne har tatt utgangspunkt i. Men jeg synes det virker som om Program manager-rollen inneholder mer enn dette.

Kanskje kunne vi hatt nytte av en klarere Program manager-rolle på prosjektene våre?

Suksessprosjekt = Suksessmetode ... eller?

Hvor stor rolle spiller egentlig metoden vi jobber etter for i hvor stor grad vi lykkes med prosjektene? Ganske stor, vil jeg si, hvis jeg ikke sa det ville jo mye av mitt engasjement i smidige metoder være rett og slett bortkastet.

Men vi må heller ikke glemme at metoden ikke er alt - les om MDD og reflekter!