Indtryk fra en IT arkitekts hverdag

Har lige gennemført et kanon projektleder kursus. Det mest interessante for mig var de bløde elementer og de indadvendte. Jeg opdagede at jeg rent faktisk evner at coache hvilket kommer lidt som en overraskelse for mig. Jeg har altid gået efter mine løsninger, men måske er det et element i at blive voksen. Derudover har jeg "taget" en meyers briggs type indikator. Der er ikke de store overraskelser i min profil (ENTJ), men det interessante er noget af den teori der ligger bagved. Specielt ens såkaldte inferiøre funktion. Det er den funktion der kommer til udtryk når man er stresset/presset. Det er ret interessant for min er såkaldt introvert følen, hvilket betyder at jeg lukker mig inde og ikke stoler på mig selv mere. Der var en masse andet godt (og nogle pm teknikker, men de har ikke udviklet sig væsentligt siden roderkonge). Jeg fik også samlet lidt krudt til kampen mellem det plandrevne og det empirisk baseret. Når men tilbage til en it arkitekts hverdag. Det ene øjeblik skal man udvikler web baseret funktionalitet til vores SCM værktøj, Dimensions. Det andet øjeblik skal man forholde sig til LEAN i it afdelingen samt forsøge at provokere vores ledelse. Så skal der udvikles en prototype i Eclipse EMF/GMF således at jeg kan vise hvorledes man kan benytte meta modellering til forskellige løsninger. Så ringer der en bruger af Serana Dimensions som ikke kan checke-in. Hmm jeg har jo ikke produktions passwordet. Hvem har det? Find en... :) Og så er det tid til at lave en præsentation af Scrum tilpasset et ikke kendt publikums specifikke behov :-) 2 timer uden vand men med fuld hammer på mundtøjet og lytterbøfferne for at finde vejen. (Gik iøvrigt godt. Jeg elsker det). Når så skal man forholde sig til overordnede styringsprincipper, hvor man ikke lige har fået noget information, men ens Scrum implementering er ret afhængig af det.... Og hvem kan lige lege med mig og hvordan laver vi et roadmap etc. etc. Så skal man også lige forholde sig til integrationsarkitektur samt brug af Spring.
Forholdsvis divers arbejdsdag og jeg elsker det et eller andet sted. Kunne være fedt hvis der var en enkelt person som man kunne køre parløb med men sådan er det nok ikke ...

Scrum i vedligehold

hmm så er vi endelige ved at være fremme ved at der skal bruges lidt tid på at indføre Scrum. Jeg skal indføre Scrum i forskellige typer af teams og projekter. En udfordring er i forbindelse med teams der har vedligeholdelsesansvar og support ansvar. Vedligeholdelsesopgaverne ryger bare ind i backlog'en (kræver lige lidt gymnastik, men ...) I forbindelse med support opgaver er jeg lidt mere i tvivl om hvorledes det skal håndteres. Der er ihvertfald to måder som jeg ser det p.t. Enten "nedskriver" man teamets kapacitet med en eller anden faktor. Og tager folk ud til de "vigtige" support opgaver der kommer. Det vil nok være den traditionelle måde at gøre det på, men jeg ser flere problemer med den tilgang. Et er at man fjerner synlighed af teamets arbejde, en anden er at man risikerer at supportopgaverne ikke ses som en del af teamets ansvarsområde og dermed opnår man ikke potentielle fordele ved at kunne sprede evne til løsning. Derudver er der en risiko for at man tilsidesætter prioriteringsarbejdet og "tvinger" teamet til at nå det de har commitet sig til selv om de rent faktisk laver andet.
Dvs. Synlighed og gruppedynamik kan lide skade ved denne måde at gøre ting på.
En anden måde som jeg lige skal har styr på er at inddrage de akutte support opgaver i backlog'en og skabe en synlighed på eksempelvis en kanban tavle. Man kunne bruge en anden type eller farve kanban. Man vil stadigvæk tilsiddesætte sprint planlægningen, men til gengæld vil der være synlighed og der vil være mulighed for scrum masteren til at kommunikere løbende. any ideas?