Udviklingsafdeling i skyttegrav
Indledningen: Når forretningen ved, de kan gøre det bedre
En dag er jeg inviteret til et møde, hvor en stor virksomhed vil høre vores mening om deres udviklingsproces.
Kort fortalt er problemet, at de i forretningen har rigtig svært ved at bestille features i udviklingsafdelingen.
De er usikre på, om de selv kan gøre noget bedre. De ved også, at udviklingsafdelingen har travlt, og historikken siger at alle features ender med at blive leveret med forsinkelse.
Vi diskuterer deres situation og bliver enige om, at det nok er en god idé, at udviklingsafdelingen er med til næste møde.
En udviklingsafdeling i baglås
Nu er vi til næste møde, hvor udviklingsafdelingen stiller op med tre chefer. Projektet har bevågenhed.
Vi forklarer om vores invitation fra forretningen, og en udviklingschef med armene over kors spørger: "Sig mig, har forretningen sendt jer i byen for at fortælle at vi ikke gør vores arbejde godt nok?" Tonen var ikke specielt mild.
Jeg forklarer, at forretningen gerne vil lære, hvordan de kan blive dygtigere til at formulere deres behov, så det bliver lettere for udviklingsafdelingen at levere. Tonen bliver pænere, og vi har et konstruktivt og godt møde. Derefter sker - ingenting.
Hvad er det lige, der foregår?
Processer i hårdknude
Det er et meget normalt mønster, og du har måske oplevet det selv.
- Det starter med at forretningen ikke beskriver det de vil godt nok
- Der er dårlig kommunikation mellem forretning og udvikling
- Udviklingsafdelingen kan ikke få svar på spørgsmål fra forretningen. De har ikke tid
- Når den nye feature levers, er forretningen utilfredse. Det var ikke, hvad de havde tænkt sig
- Nu graver udviklingsafdelingen en skyttegrav. Forretningen kan bare komme an..!
Det er aldrig let at arbejde sammen med udviklere, der har armene over kors, og jeg kan sagtens se problemet fra begge sider. Men hvad gør man?
Definition of Ready
Mange agile projekter arbejder med en Definition of Done, der beskriver hvordan en feature vil blive testet og godkendt. Det bør man også have, men det er ikke nok.
Ikke så mange agile projekter har en Definition of Ready, der beskriver hvornår en feature er beskrevet godt nok, så den må indplaceres i et sprint. Men det er faktisk en stor fejl.
En Definition of Ready anvendes til at bestemme, hvordan en feature skal beskrives helt ned i detaljen. Ikke at det behøver at være en lang smøre - det er bedre at gøre det kort.
Jeg plejer at bruge et enkelt format:
- En user story (som brugeren Henrik vil jeg tilmelde mig nyhedsbrevet for at få nyheder i min inbox hver uge
- Acceptkriterier (Givet at jeg indtaster min email-adresse, og at den validerer, og at jeg trykker på knappen... osv.)
- Eventuelle fakta (Hvilke plattforme og integrationer er i spil)
- Variationer over et scenarie (Denne feature bruges også af interne medarbejdere til at tilmelde deres kontaktpersoner efter aftale)
Hvis forretningen skal blive glade for en Definition of Ready, skal der både være en eksempel-tekst og en person, man kan ringe til, når man er i panik.
Fordelen ved Definition of Ready er, at vores projekt nu har to stabile tilstande.
Vi ved, at alt vi lukker ind i sprintet er i god kvalitet. Som udvikler ved man, hvornår "det er godt nok", for acceptkriteriet er skrevet ned. Det er ikke smagsdommeri ved afleveringen.
Forretningen bliver glade, for det bliver lettere for dem at skrive specifikationer. Det bliver lettere at tale sammen på tværs af afdelinger. Test-teamet ved, hvordan en feature skal testes.
I mange projekter vil forretningen faktisk gerne hjælpe udviklingsafdelingen ud af skyttegraven. Det er også sjovere at gå på arbejde, når der ikke er krig.
Om Martin FrederiksenMartin er CEO i Klean Group, hvor de hjælper andre med at se klart, skære fedtet fra i it-projekter og redder projekter, der er gået galt. Martin arbejder med strategisk rådgivning af større virksomheder og Kleans internationale vækst. Martin blogger om projekter der er gået galt.
Follow @martinmichaelKommentarer (10)
Min erfaring siger mig at alle afdelinger har en skyttegrav. Også forretningen og også testafdelingen. Og jeg tror også gerne at udviklingsafdelingen vil hjælpe forretningen ud af skyttegraven. Den går begge veje. Forestil dig at det er udviklingsafdelingen som hyrer et eksternt firma til at fremme den interne kommunikation i virksomheden. Så vil forretningen måske også sidde med armene over kors til de første par møder - uanset hvor gode intentionerne er. Og det er aldrig let at arbejde sammen med forretningsfolk, der har armene over kors :-)
Løsningen på problemet er ikke nødvendigvis mere dokumentation i form af "Definition of Ready", men kan ofte være mere direkte verbal kommunikation mellem fx forretning, udvikling og test. Hvis muligt, så placer disse folk i samme fysiske rum i udviklingsforløbet. Så opstår der en ny afdeling (et projekt), som har bevæget sig op af skyttegraven, hvor der kommunikeres hurtigt og præcist på tværs af afdelingsgrænser.
-
6 -
0
Enig.
Men overordnet lydder det lidt somom, man forsøger lidt at presse "Forretningen specificere, udviklingen leverer" ned over det hele. Så fungere tingene bare ikke i praksis. Udviklerne skal også have plads til at "hitte på" ny funktionaliteter og måder at gøre produkterne lidt smartere på. Det kræver også en tæt tilknytning til forretningen.
Den specifikationsdrevne model, hvor forretningen specificere produktet og udvikligen så "blot" skal levere, dræber inovation. "Forretningen" har sjældent andet end gamle produkter og konkurrenter at få inspiration fra. Så opfinder man jo altså ikke noget nyt, og kommer slet ikke foran konkurrenterne.
-
7
-
0
Der er noget grundlæggende galt med mindsettet, hvis udviklingsafdelingen ikke føler sig som en del af "forretningen". Det er altid en fordel at huske på, hvem der betaler ens løn - og det er ikke chefen eller ledelsen - det er kunderne.
Dermed bestemt ikke sagt at salgs-/kundeafdelingen skal tromle udviklingsafdelingen, "blot" at en fælles forståelse for, at det, at alle arbejder mod samme mål, er helt afgørende.
Målet bør være: Bedre produkter til gavn for kunderne og dermed (hele) "forretningen".
Løsningsmulighederne indbefatter bl.a. (som Anders Pallisgaard nævner) sammensættelse af tværfaglige projektteams, som er placeret fysisk sammen og hvor alle medlemmer på ét eller andet niveau er involveret i kundekontakten - og som dermed gennem en fælles ejerskabs-/ansvarsfølelse på lige fod kan bidrage til at forbedre "forretningen".
-
3
-
0
Jeg er helt enig i, at det er en rigtig god idé at placere forretningen og udviklingsafdelingen i samme rum, men det er ikke altid det kan lade sig gøre.
Mange projekter lider af at have lav prioritet. Det kan være, at udviklerne har som primær opgave at arbejde med projekt X, men de skal også løse opgaver i projekt Y.
Derfor er det jo ikke meningen at projekt Y skal gå i vasken, men det kan være svært at være udvikler på et projekt med lav bevågenhed - og hvis forretningen så ikke har tid til at være med, så er det for alvor svært.
Jeg holder i øvrigt 100% fast i, at en Definition of Ready både er en god idé og på ingen måde ekstra dokumentation. Jeg vil til enhver tid nægte at løse en opgave, der ikke er tænkt igennem, og Definition of Ready skal ikke være andet end den minimale - men nødvendige - dokumentation, der sikrer at man ikke koder i blinde.
Som udvikler vil jeg også gerne tilbyde forretningen at hjælpe dem med opgaven, men som minimum skal der være tid til at mødes og tale sammen. Tro det eller ej, men hvis I andre sidder i projekter, hvor udvikling og forretning er rigtig tæt på hinanden, så er I heldige end gennemsnittet. :-)
Som Andreas skriver er det fælles mål afgørende, men for mange er det svært at gennemføre i praksis.
-
2
-
0
Jeg synes at konceptet med at definere hvornår en opgave er beskrevet ordentligt er god. Selv har vi haft meget opmærksomhed på samme problem i de sidste projekter, hvor jeg har deltaget. Det har heldigvis ikke været svært at overbevise forretningen om at investere tid i at specificere bedre.
Til gengæld synes jeg at dette her:
Mange projekter lider af at have lav prioritet. Det kan være, at udviklerne har som primær opgave at arbejde med projekt X, men de skal også løse opgaver i projekt Y.
...er et problem: der findes jo ikke "høj prioritet" og "lav prioritet". Det eneste man kan beslutte er hvilke opgaver der skal løses først. Scrum-folkene taler om at det er forkert at sige at en backlog er prioriteret - den er ordnet. Vægten lægges altså på at man bliver færdig med opgaverne i en bestemt rækkefølge.
Så kan man aftale at udviklingsafdelingen selv kan afgøre hvad rækkefølgen for en given bunke opgaver skal være og deraf kan man komme til at konkludere at de har samme prioritet. Det er bare en meget konkret fortolkning af prioritet - at ingen opgaver påbegyndes før andre med højere prioritet er helt færdige.
På mange måder mener jeg at det er sundt at simplificere arbejdssituationen for udviklingsafdelingen på denne dimension - at man ikke opererer med opgaver som er i gang, men som ikke er helt så vigtige som andre. Omkostningerne forbundet med at have en opgave åben i lang tid hvor den ikke får tilstrækkelig opmærksomhed er så høje, at det ofte ikke kan betale sig at planlægge på den måde.
Jeg ved godt at virkeligheden kan være en anden, men der er ingen grund til at tage det for givet at man arbejder med almindelige, "fuzzy" prioriteter.
-
3
-
0
Jeg sad faktisk igår aftes og tænkte på at nu var Agile ved at time ud og at det næste buzz-word mirakel burde være under opsejling, fantastisk timing:
"Mange agile projekter [...] men det er ikke nok.
Ikke så mange agile projekter har en Definition of Ready, [...]"
bingo!
Gør klar til at høre foredraget, læse bogen, deltage i kurset, prøve selv og blive lige så skuffet som altid over at miraklet ikke virker.
-
3
-
0
Høhø. For mig er det faktisk lidt ligemeget om projektet er agilt eller ej.
Definition of Ready er et værktøj i kassen på lige niveau med så meget andet, men det viser sig faktisk at være praktisk i projekter, hvor forretningen leverer for dårlige beskrivelser og hvor udviklerne går i gang uden at vide hvad succeskriteriet er.
Vi kan alle sammen blive enige om, at hvis forretningen og udviklingen bare sad sammen og forstod hinanden som de bedste venner, ville det hele være meget lettere.
Michael, jeg fik måske ikke forklaret mig ret godt da jeg skrev om projekter med høj og lav prioritet, men et typisk eksempel fra min hverdag er, at der skal laves en e-commerce løsning med integration til et økonomisystem. I sådan et projekt, har web-teamet brug for kompetencer fra virksomhedens interne it-afdeling. De bliver ikke målt og vejet på, om e-commerce løsningen fungerer til tiden, men på om kasseapparaterne kører i butikkerne og om Navision er i luften hele tiden.
I sådan et projekt, agilt eller ej, kan det være umuligt for web-teamet at få hjælp fra intern it fordi projektet ikke har høj prioritet for dem. I den slags projekter kan opgaver godt være i gang, men de kan hænge i flere måneder af årsager, som web-teamet ikke kan gøre noget ved.
Poul-Henning, du kan godt komme på kurset, men det tager kun fem minutter og det er ikke en mirakelkur. :-)
-
1
-
0
Jeg sad faktisk igår aftes og tænkte på at nu var Agile ved at time ud og at det næste buzz-word mirakel burde være under opsejling, fantastisk timing[...]
Menøh Poul-Henning - har du prøvet Scrum?
Jeg siger bestemt ikke at det er vidunderligt, men din kommentar mere end antyder at du reelt ikke har prøvet det i praksis.
-
0
-
0
Gør klar til at høre foredraget, læse bogen, deltage i kurset, prøve selv og blive lige så skuffet som altid over at miraklet ikke virker.
"Definition of Done" og "Definition of Ready" er ikke nye terminologier, det er i hvert fald fire år siden jeg hørte om den første gang, og der er intet helligt eller mirakuløst i det – det er bare god og sund fornuft.
-
1
-
0
Går udviklingen ikke imod at IT afdelingen splittes op i en driftsafdeling (den der let kan outsources) og i en udviklingsafdeling (den der ikke så let kan outsources)?
Udviklingsafdelingen bør sidde meget tæt på forretningen og være styret af forretningens ønsker/krav/prioritering - ellers kupper forretningen den bare og tager livet af den.
Det man oftest ikke bruger krudt nok på er Product Owner rollen. Henrik Kniberg har lavet en rigtig god video om emnet: link til YouTube.
-
1
-
0
Tilføj kommentar
