Produktorganisering og produktledelse med Atlassians verktøy

Mange selskaper ser seg om etter gode løsninger for å støtte en omstilling fra prosjektdrevet utvikling til produktorganisering med faste autonome team. For at autonomi skal fungere med felles retning er tydelige mål og et tight-loose-tight ledelsesparadigme en forutsetning. Men hvordan kan vi støtte teamene med gode metoder og verktøy? Dette har vi Computas Digital Work Design hjulpet selskaper med i en årrekke, her er noen av våre anbefalinger:

Styringsnivåer i en organisasjon — “Flight Levels”

Produktorganisering medfører en omstilling av en hel virksomhet til å jobbe mer smidig, koordinert og strukturert mot strategiske mål med klare prioriteringer. Da kan følgende modell hjelpe til med å få oversikt over behovene som må dekkes. Den gir alle involverte et felles bilde å koordinere innsatsen ut fra. Ideen er hentet fra Rethinking Agile: Why Agile Teams Have Nothing To Do With Business Agility av Klaus Leopold:

Flight Level 1: Operational Level

• Fokus: Teamnivå, enkeltoppgaver, og daglig arbeid.
• Mål: Forbedre effektiviteten i hvert enkelt team.

Flight Level 2: Coordination Level

• Fokus: Koordinering mellom ulike team og avdelinger.
• Mål: Sikre at arbeidet som utføres på operasjonelt nivå er i tråd med organisasjonens overordnede mål og at det er god flyt i verdikjeden.

Flight Level 3: Strategic Level

• Fokus: Organisasjonsstrategi og langsiktige mål.
• Mål: Sikre at nok ressurser er rettet mot de mest kritiske initiativene for organisasjonen.

Hvert nivå har gjerne sine behov og utfordringer. For hvert nivå begynner vi derfor med å se på hvor vi er i dag og definere en måltilstand, identifisere hindringer på veien dit og legge en nødvendig strategi for å håndtere disse. Vi begynner ikke med å si at det er fritt fram å velge metode og verktøy i teamene på nivå 1 for senere å finne ut at de har valgt fullstendig ulik tilnærming! Da vil vi fort finne ut at koordinering og prioritering basert på strategisk retning blir en utfordring. Det betyr ikke at alle team må bruke det samme verktøyet!

Hvert nivå “ser verden” fra ulik detaljeringsgrad og har behov for støtte for arbeidsprosesser og oversikter. Disse kan godt realiseres i ulike verktøy, men vår anbefaling er at med en gjennomtenkt og integrert verktøyrigg, godt gjennomgående design og opplæring i nye arbeidsmetoder kan man spare mye friksjon og manuelt arbeid.

Merk! Flight levels er ikke et organisasjonshierarki der noen “bare jobber med strategi” og andre bare koordinerer eller koder. I en ideell smidig organisasjon med selvstendige team jobber ett og samme team på alle nivåene innenfor sin verdistrøm eller produkt.

Hvert team vil ha behov for å få hele vertikalen til å henge sammen. Kan hende er organisasjonen langt unna dette i dag, men flight-level perspektivet på abstraksjonsnivåer vi trenger å forholde oss til gjelder uansett hvordan det faktisk organiseres.

Det er utilrådelig å innføre verktøy for et behov du bare halvveis forstår, så først – la oss se på hvilke spørsmål vi stiller oss under kartleggingen av behov på hvert nivå:

Forstå behovene på hvert nivå

For hvert spørsmål kan vi grave i hvordan, og ikke minst hvorfor ting er som de er i dag, men også sette opp noen ønsker for hva vi vil oppnå i fremtiden.

Flight Level 3 — Forretningens strategi og portefølje:

• Hvilke produkter og tjenester leverer vi, egentlig? Hva er vår produktstrategi, og hvilke føringer legger dette for vår inndeling og organisering av team og ansvarsområder?
• Målstyring/OKR. Hvordan foregår prosessen med å definere og prioritere mål for produktene og tjenestene? (Den første Tight-en)
• Budsjett, allokering av midler — hvordan skjer dette? En gang i året eller basert på løpende vurderinger og påviselig nytte? Trenger vi en endring her?
• På hvilket utviklingsstadium befinner de ulike produktene og tjenestene seg? Hvor handler det om kjente oppgaver og hvor er det mye utforskende arbeid? Disse krever ulik metodisk tilnærming, ikke innfør Scrum overalt!
• Hvordan driver og styrer vi product discovery arbeid? Hvordan bør inntaksprosessen for nye initiativ og forbedringsforslag være?
• Ledelses- og styringsfilosofi: Hvordan sikrer vi felles forståelse for hva smidig forretningsdrift er og hvordan tilrettelegger vi dette? Hvordan forstår vi Outcomes vs. Output i vår forretningskontekst? Hva trenger ledelsen å avlære?
• Hvordan driver vi oppfølging av måloppnåelse i praksis? Hvilke føringer legger dette for valg og bruk av verktøy? (Den siste Tight-en)

Flight Level 2 — Koordinering mellom strategiske prioriteringer og operasjonell drift og utvikling

• Hvilke typer arbeid må vi håndtere? F. eks: nyutvikling, bugfiks og refaktorering, drift, support, krisehåndtering. Hvilke prinsipper har vi for fordeling og prioritering av ulike typer arbeid? Dette er ofte en kilde til mye diskusjon og frustrasjon i team som treffes av behov “fra alle kanter.”
• Hvordan står det til med avhengigheter mellom team og hvor mange initiativer er i prosess per team? Hvordan kan vi unngå å skape et stort koordineringsbehov med bedre organisering og fordeling av arbeid?

• Produktledelse og produkteierskap i praksis — Hvilke mekanismer og fora har vi for løpende prioritering og tilpasning til endringer i omgivelsenes/kundenes krav og ønsker? Hva er modenhetsgraden vår her? Er det behov for opplæring/coaching?
• Kapasitetsplanlegging: gitt arbeidets natur, varighet og omfang— hvor egnet er faste produktteam kontra prosjekter? Spiser multitasking og kontekstbytte opp kapasiteten? Er det knapphet på noen ressurser? Hvordan forholder vi oss til begrenset kapasitet når det kommer til ambisjoner på strategisk nivå?
• Hvordan sprer vi læring på tvers?

Flight Level 1 — Operasjon i teamene

• Hvordan står det til med smidig praksis i teamene — Hvis “Scrum liksom skal følges,” som mange sier: hvordan forholder vi oss til produktmål, sprintmål, sprintplanlegging, reviews og retrospectives? Har teamene verktøy som er rigget for å støtte dem i dette og hvordan brukes de egentlig?
• Leveranseevne, kompetanse og redundans i teamene — er vi et team med et felles mål som vi er avhengig av hverandre for å nå, og hvor godt kan vi utfylle/erstatte hverandre?
• Relasjoner og kommunikasjon: hvem er teamets stakeholdere og hvilke avhengigheter har vi til ressurser utenfor teamet? Hvordan kommuniserer vi med disse?
• Compliance, arbeidsprosesser og fasilitering — er vi underlagt regulatoriske hensyn til etterlevelse av prosesser og dokumentasjon av dette? Hvordan fasiliteres dette arbeidet?
• Oversikt over arbeid — hvordan beskrives/spesifiseres arbeid — f.eks. hva er det vi legger inn i Jira, egentlig? Når? Skal vi beskrive mål og behov kontra “lukkede” løsningsrom med feature/task fokus? Hvordan sørge for god oppgavenedbryting og estimering? Her er det mange som har mye å hente.
• Samarbeidsklima: Team contract og Team helsesjekk kartlegger hvordan team ønsker å jobbe sammen og hva de har behov for å forbedre.

Ledelse og styringsparadigme

Det finnes mange ulike bedriftskulturer og de vil alle være formet av det rådende ledelsesparadigmet i selskapet: Hvordan forholder vi oss f.eks. til ansattes medvirkning og medbestemmelse, hvilke incentivordninger finnes og hvilken adferd fremmer de, har vi tillit til fagkunnskap og gjennomføringsevne eller føler vi at vi må overvåke og følge opp alt, hvordan står det til med ledelsens evne til å delegere og gi slipp på kontrollbehovet, hva slags møtekultur har vi, etc.? Hvis man ønsker å endre seg i retning mer ansvarliggjøring av team som skaper verdi med smidighet, fart og flyt er det også nødvendig med noe selvransakelse her.

Du kan ha verdens beste oppsett av hjelpemidler for å fremme autonome team men det vil ikke resultere i noen forandring hvis ledelsen fortsetter å skulle ha en finger med i alle detaljer, gamle godkjenningsrutiner ikke endres eller alle er med på alle møter av frykt for å gå glipp av noe.

Atlassian verktøyrigg for produktutvikling

Atlassian er mest kjent (elsket eller hatet) for oppgavestyringsverkøyet Jira og enterprise wikien Confluence. Men visste du at filosofien bak hele selskapet hander om å støtte all slags teamarbeid? I tråd med dette har de utviklet et par nye hjelpemidler som er særlig egnet til å begeistre produktorganisasjoner med distribuert ansvar. Atlassian er jo selv en produktorganisasjon, så de har utviklet de verktøyene de savnet i sin egen hverdag.

Jira Product Discovery

For å begynne med strategi og prioritering: Jira Product Discovery håndterer inntaksprosessen for nye (produkt)ideer. Ambisjonene har en tendens til å overskride kapasiteten i alle organisasjoner, så vi må prioritere, og hvordan gjør vi det? Transparente prosesser, gode vurderinger og ikke minst samarbeid i ett felles verktøy gir oversikt og trygghet for at de mest verdifulle ideene er de vi satser på. Ideer kan legges inn vha. tilpassede skjermbilder. Innsikt som støtter beslutninger, enten de kommer fra egne analyser eller kilder på internett kan knyttes inn og benyttes i prioriteringsprosessen. Hvilke mekanismer vi baserer prioriteringene våre på legges inn ved hjelp av felter med verdier for f.eks. effort, impact, customer value og kan benyttes i vektede funksjoner til scoring på tvers, og uten videre tilpasning vises i oversikter som f.eks. en effort vs. impact matrise. Jira Product Discovery er utviklet fra bunnen av og ser ikke ut som Jira i det hele tatt, noe som begeistrer de som kanskje mistenker at dette blir komplisert å bruke. Her kan man enkelt legge inn nye felter, funksjoner og oversikter uten noen administratorkunnskap.

Når en ide er besluttet verdig for et eksperiment kan den enkelt kobles til Jira Software eller Jira Work Management for implementasjon i teamene, som jobber videre i disse verktøyene med å bryte ned oppgaven og følge opp framdrift.

I en produktorganisasjon med mange team og mange pågående initiativer kan det være en krevende jobb å følge med på alt som skjer — hvor trengs det hjelp og tiltak, hvor går alt på skinner, hvilke nye innsikter har vi fått og hvilke ny risikoer er avdekket? Produktutvikling er kunnskapsarbeid i en kompleks virkelighet, så signalene forsvinner fort i støyen hvis vi må forsøke å fatte det store bildet ut fra en masse oppgaver og dashboards med statistikk. Selv kryssfunksjonelle team kan bli siloer! Det Atlassian selv innså var at korte, velartikulerte, hyppige oppdateringer skrevet av ekte mennesker langt er å foretrekke framfor omfattende statusmøter eller dashboards fulle av tall. Så da lagde de verktøyet Atlas.

Atlas for oppfølging

I Atlas definerer man mål og initiativer/prosjekter som man så kan legge inn månedlige eller ukentlige oppdateringer for, enten det er ny læring, ny risiko eller bare en kort status. De ansvarlige får påminnelser om å gjøre dette, og de interesserte abonnerer på de målene og initiativene de er interessert i å følge med på. Disse kan også tagges med definerte tema, som du så kan følge slik at du får alle oppdateringer som gjelder f.eks. temaet kundetilfredshet eller AI-satsing.

Videre kan mål og initiativer definert i Atlas knyttes til idéer i Product Discovery slik at en kan se hvilke mål en idé er med på å støtte. Man kan også knytte f.eks. et Epic i Jira til et initiativ i Atlas og rett fra Epicet se alle løpende oppdateringer som er skrevet i Atlas uten å hoppe mellom verktøy. Det fine med Atlas er at man godt kan knytte mål og initiativer herfra til helt andre verktøy for oppfølging, ikke bare Jira — så teamene trenger ikke nødvendigvis bruke samme oppgavehåndteringsverktøy. Å sikre at vi jobber i samme retning mot felles mål blir straks betydelig enklere. Mange benytter også Atlas til nettopp oppfølging av OKR — der et mål (objective) har sub-mål (Key results) som kan scores og direkte knyttes til de initiativene man har iverksatt og følger opp i Jira.

Apropos følge opp i Jira — har du forsøkt å få oversikt over mange Jiraprosjekter på tvers? Ikke helt lett uten enten Excel eller en addon — vel, nå har du Jira Plans.

Jira Plans (Advanced Roadmaps)

Jira Plans er designet for å adressere kompleksiteten i porteføljestyring i smidige organisasjoner. Det løser utfordringer som helhetlig oversikt over alle initiativer, noe som gjør det lettere å prioritere og allokere innsats effektivt. Med funksjoner som tidslinjer og avhengighetskart, hjelper det teamene med å forstå og planlegge for avhengigheter mellom ulike oppgaver og milepæler, og med avanserte rapporteringsfunksjoner kan produktledere ta mer informerte beslutninger basert på sanntidsdata.

Det er spesielt nyttig for store organisasjoner med flere team og initiativer som går parallelt og er kompatibelt med f.eks. Scrum og Kanban, så ikke la deg forlede av Gantt-tidslinje-viewet til å starte med big planning up front!

Riktig redskap er halve jobben

Å legge til rette en god verktøyrigg som støtter arbeidet på alle nivåer med nødvendig oversikt på tvers og helhetlig sammenheng vertikalt består i å sette opp en god flyt fra idé til leveranse, via Jira Product Discovery og Jira Service Management til Jira Software med Plans. Hvordan kommer arbeid inn i hvilke team og hvordan kan teamene visualisere og prioritere når de har ulike klasser av arbeid å forholde seg til? For å forstå hvilke problemer som må løses bør dere starte med en felles analyse av de spørsmålene jeg innledet med for hvert nivå.

Til slutt: ikke glem at etter at en løsning er initielt designet og tatt i bruk, må videre forvaltning håndteres av personer som føler tilstrekkelig ansvar, har tilstrekkelig kompetanse både på forretningen og på verktøyene og har nødvendig kapasitet. Ellers er hele innsatsen fort bortkastet og kaoset vil klappe sammen over oss som Rødehavet etter Moses, nok en gang.

---

Produktorganisering og produktledelse med Atlassians verktøy was originally published in Compendium on Medium, where people are continuing the conversation by highlighting and responding to this story.