Några ord från Agical

Har du tagit din Jira-ticket?

Anette Lovas Ulrika Vincent

Har du tagit din Jira-ticket?

Om du går till nästan vilken IT-avdelning som helst idag, som utvecklar digitala produkter och tjänster, så möts du av Jira. Den nya tidens standardverktyg för att “hantera krav”. Du kanske till och med får höra att “här jobbar vi agilt, allt vi gör ligger i Jira” (att just det uttalandet är ett missförstånd går vi in på en annan gång)

Så här kan det låta på ett morgonmöte:

“Har ni tagit er Jira-ticket för dagen?”

“Nähe inte… men vi måste ju göra det! Ta en!”

Snarare än:

“Vad är det viktigaste att göra idag?”

“För vem och varför?”

Låter det här bekant? Utvecklings-teamets arbete ska organiseras och prioriteras via Jira. Och det är inte bara teamets arbete… utan alla som jobbar med produktutvecklingen. Varifrån kommer alla dessa Jira-tickets? Jo, från övergripande features eller s.k “Epics” som skrivits och scopats av någon. (En “Epic” i Jira är en ticket som ska hålla ihop en mängd mindre funktioner eller uppgifter “Stories”) Ofta skrivs dessa Epics och Stories utan särskilt mycket inblandning av teamet som är de som ska utveckla produkten.

Varför är det ofta så att Jira-ticketsen spretar och springer åt olika håll? Det blir ett tufft jobb för en “Epic” att hålla ihop helheten.

Tanken är god när produktägare, projektledare, kravanalytiker eller andra skriver ner sina tickets.. Krav måste brytas ner och man vill säkerställa att det som ska göras blir gjort. Därför dumpas oändligt många tickets i Jira, och författaren går nöjd och glad hem för dagen. Men, gör vi verkligen rätt saker? Kommer jobbet ens att bli gjort bara för att den där ticketen landar i Jira på samma vis som om ett flygplan släpper fallskärmshoppare och hoppas att de landar på rätt ställe? Förstår alla i teamet och intressenterna vad vi vill göra? Vem tar egentligen hand om helheten, och säkerställer att vi löser det riktiga problemet?

Bidrar verkligen arbetssättet med Jira-tickets och modellen Epic/Features/Storys att vi löser de verkliga problemen och behoven hos våra kunder och användare? Eller bygger vi bara ett stort lapptäcke av funktioner utan helhet, som ingen vet vad de är bra för?

Vi undrar vad som hände med behovsanalysen? Den där lilla detaljen som skulle hjälpa oss att klargöra vad vi faktiskt ska göra, för vem och varför? Istället står vi här med en hög Jira-tickets, som ingen vet var de kom ifrån. Vi kan likna det med att försöka laga middag utan att veta vad vi har i skafferiet eller vilken rätt vi vill laga! Vi kastar ihop en soppa på det som finns, men är det verkligen det vi vill göra när vi tar fram nya eller utvecklar befintliga produkter?

Processen är det nya målet?

Utöver fokuset på Jira-tickets, snarare än helheten och de faktiska behoven, så märker vi att det också har blivit allt viktigare att genomföra de s.k “Scrum-ceremonierna” än att samma ceremonier faktiskt hjälper oss framåt.

Vi har haft goda erfarenheter av metoden Scrum som hjälp för struktur och ordning, särskilt i nya utvecklingsteam, men något har gått överstyr. Att genomföra en halvdags sprintplanering, en releaseplanering eller ett retrospektiv, oavsett om det är vad teamet behöver eller inte, har blivit viktigare än att… planera, utvärdera och reflektera, som var tanken från början.

I alltmer stökiga, integrerade och tekniskt komplexa miljöer och marknader kan det vara något helt annat teamet behöver för att få struktur, energi och fokus än att genomföra ytterligare en sprintplanering.

Så här kan svaret bli när någon ifrågasätter behovet av en viss rutin. “Vi måste alltid förhålla oss till de regler och ceremonier som vi committat oss till! Standups, retros, sprint-planeringsmöten… måste hållas med jämna intervall, och de måste faciliteras av en ScrumMaster!!”

“Designen då?”, frågar vi

“Designen ska utformas som en egen sprint innan teamets utvecklings-sprint. för det är så vi har bestämt i processbeskrivningen”

Vi ifrågasätter att rutinerna alltid måste följas till vilket pris som helst. Hallå kollegor! Lyfter vi blicken tillräckligt ofta? Är designsprint alltid det bästa sättet? Är ett retrospektiv som går på rutin utan att ge särskilt mycket, alltid mer värdefullt än en skogspromenad eller att slå sig ner och rita en modell tillsammans?

Det är avgörande att team arbetar effektivt och målmedvetet. Trots de bästa intentionerna kan det ofta upplevas som om vi hamnar i en loop av processer och verktyg, där Jira har fått en särskild roll som “rättesnöre”. Där själva kärnan av vårt arbete – att lösa verkliga problem och behov – hamnar i skuggan av verktyget och den överenskomna processen.

Det är dags att ändra på något och se till att alla i teamet har möjlighet att både förstå behoven och påverka prioriteringarna . Produkt- och systemutveckling handlar inte bara om att följa en uppsättning regler eller procedurer, det handlar om att tillsammans skapa en kultur där vi vågar ifrågasätta och diskutera vad som verkligen behöver göras, och hur vi kan uppnå det.

En erfaren facilitator, t.ex en ScrumMaster, är ofta både nödvändigt och bra, men det var aldrig tanken med Scrum eller någon annan utvecklingsmetod att den facilitatorn skulle bli process-paragrafryttare!.

I slutänden handlar det om att återförenas i vår strävan att förstå och lösa de problem som våra kunder och användare står inför. Låt oss inte bara se våra arbetsuppgifter som lösa tickets i ett system, utan som en del av en större berättelse – en berättelse där varje teammedlem har en viktig roll att spela.

Tillsammans kan vi skapa en arbetsmiljö där vi inte bara är effektiva, utan även meningsfulla.

Anette Lovas

Anette Lovas arbetar idag som agil coach och UX-expert på Forefront. Hon har tidigare haft ledande roller på bland annat Expressen, Spotify, HM, Telia m.m och som kursansvarig på Berghs School of Communication. Genom åren har hon hjälpt organisationer att utveckla kunddrivna, digitala lösningar med fokus på användarupplevelse och förändringsledning.

Ulrika Vincent

Ulrika has a background as a software developer, product leader & analyst, manager, agile mentor and other roles in digital development. Last couple of years she’s developed her coding skills in data analytics, statistics & Python. She has been working with several popular mobile apps, web services & other platforms in Sweden such as Res I Sthlm, Travis, SL, Expressen, KTH, Fritidsresor (TUI), Coop, Lantmännen and SoapUI.

Ulrika has a passion for problem solving, data driven work and understanding the users real needs. She encourages self directing and cross functional work, testing, open data and learning.

You can contact her for open questions or support within digital product development