En av anledningarna till att kyrkogården med misslyckade utvecklingsprojekt är så full är att man många gånger försökt angripa systemutvecklingsprocessen som om det varit ett förutsägbart husbygge som kan utföras sekventiellt bara man följer en på förhand framtagen ritning.

Som ett svar på den sekventiella utvecklingsprocessen brister (mest känd som vattenfallsmodellen) föddes under 90-talet det agila tankesättet med mål att ge inblandade bättre verktyg att hantera den komplexitet som uppstår i samband med systemutveckling.

Agil utveckling

Det Agila arbetssättet är uppbyggt av en samling värderingar definierade i Manifesto for Agile Software där individer och interaktioner prioriteras framför processer och verktyg. Det centrala i det agila arbetssättet är att skapa för kunden värdefull programvara. Värde skapas främst genom att individer kontinuerligt jobbar tillsammans mot ett gemensamt mål. Fokus ligger på att ge de inblandade verktyg för att enklare kunna samarbeta och ger dem mandat att göra informerade vägval. Fokus är på transparens, deltagande och samspel.

I en agil utvecklingsprocess prioriteras fungerande programvara framför omfattande dokumentation då det är svårt, om inte omöjligt, att på förhand dokumentera vad som kännetecknar en framgångsrik tjänst på det sätt som den traditionella vattenfallsmodellen förespråkar. Istället väljer man att dela upp arbetet i mindre delar (iterationer om ca 3-4 veckor) för att efter varje iterations slut leverera efterfrågad funktionalitet som berörda intressenter kan utvärdera på egen hand. På så vis kan användarna ge värdefull feedback tidigt så att tjänsten kan förbättras kontinuerligt.

Kundsamarbete prioriteras framför kontraktsförhandling.
Det är genom att team-medlemmar från olika discipliner kontinuerligt samarbetar med kund som värde skapas och nya insikter fås. Genom att lära känna och sympatisera med de för vilka man tar fram IT-tjänsten ökar sannolikheten att ett bra jobb görs. Att som i traditionell systemutveckling involvera berörda intressenter i början och slutet av projektet räcker inte för att skapa tjänster som motsvarar deras behov och önskemål.

Anpassning till förändring prioriteras framför att följa en plan. När interna och externa förutsättningar ständigt förändras under tiden man tar fram en komplex mjukvarutjänst är det kritiskt för inblandade parter att kunna agera snabbt på förändring. Agila metoder rätt implementerade fungerar som en GPS som kan justera kursen när destinationen förändras. Teamet inspekterar var man är och vad som har hänt och har förmågan (i form av mandat och rätt verktyg) att agera snabbt och produktivt på förändring.

Slutord

Konceptet agilt arbetssätt handlar om att vara lättfotad och att snabbt anpassa utvecklingsarbetet när förutsättningarna förändras. Genom att arbeta agilt kan två av de vanligaste fällorna vid systemutveckling undvikas – att utvecklarna inte förstår varför och vad användarna vill åstadkomma med systemet och att beställarna har svårt att uttrycka sina behov då de inte vet vad de kan begära och vad de kan få.

Detta är ett av flera inlägg som kommer behandla olika aspekter av agil utveckling. Om någon har några frågor eller funderingar tveka inte att kontakta oss på Creating Value.

Image courtesy of jesadaphorn at FreeDigitalPhotos.net

Men det finns något som skaver lite.

Överallt ser man skyltar som säger att ”här får du inte gå”. Går man ifrån huvudspåret mot någon spännande stig möts man snart av skylten ”restricted area”. Jag blir väldigt nyfiken och vill veta vad som döljer sig bakom den, men eftersom jag är svensk och van att följa regler respekterar jag den. Amerikanerna verkar ha anpassat sig än mer och verkar inte ens nyfikna på vad som finns på andra sidan. Jag får en stark känsla av ”vi” och ”dem”. Vi som följer reglerna och dem som bestämmer. 

Det är också tydligt för barnen. På lekplatser får man leka i en säker miljö, men springer man eller klättrar någon annanstans (t ex på ett köpcentrum) riskerar man en tillsägelse från antingen en säkerhetsvakt eller annan auktoritär vuxen. Man lär sig tidigt vad man får göra och vad man inte får göra och det framgår med all tydlighet. 

Jag börjar fundera över om den här kulturen även präglar amerikanska arbetsplatser, och bilden blir snabbt bekräftad. Alla jag pratar med ger en bild av en arbetsplatskultur där chefen bestämmer och de anställda lyder. Alla företag marknadsför en bild av högt i tak i syfte att locka kompetens – men taket är ändå aldrig högre än chefens beslut eller icke-beslut. Detta skapar en oerhörd rädsla att göra fel och de allra flesta har lärt sig att det är bäst att foga sig. Är det restricted area är det bäst att man förhåller sig till det och inte går över gränsen. Och vi pratar ändå Silicon Valley – kanske världens hetaste marknad.

Ibland ser man de här tendenserna även i Sverige, men jag skulle ändå vilja påstå att våra ledare har en annan syn på sig själva och deras roll i organisationen. Jag ser oftare en genuin vilja att utveckla verksamheten med hjälp av kompetenta medarbetare och även ifall interna synpunkter ibland svider tar man de till sig i syfte att förändra till det bättre. 

Så på samma sätt som vi i Sverige har en allemansrätt där alla har tillträde har vi kanske också en kultur som i relativt hög utsträckning tillåter deltagande med få restricted areas. Åsiktskorridoren kan visserligen ibland uppfattas som smal men i grunden tror vi på och främjar allas rätt att delta och påverka. 

Av den här anledningen fortsätter jag att åka till USA på semester, men det är i Sverige jag vill arbeta och vara med och utveckla organisationer tillsammans med engagerade ledare och kompetenta medarbetare. 

Agilt är sedan några år tillbaka ordet på allas läppar, och kan sättas i samband med såväl systemutveckling och projektledning. För att förenkla (väsentligt) kan man säga att det handlar om att leverera mindre delar istället för större, vilket medför en rad fördelar:

• Man kan mer i detalj planera för hur varje del ska genomföras utan att behöva ägna sig alltför mycket åt change management vilket sparar tid både för projektledaren och projektägare/styrgrupp
• Man får möjlighet att testa och validera ofta, vilket minskar risken att projektet drar åt fel håll 
• Man kan kontinuerligt justera riktningen, då ett projekt per definition är något osäkert där vi inte på förhand med säkerhet känner till slutresultatet

Det här är väldigt stora fördelar som väl motiverar att man väljer en agil projektmodell, men det finns emellertid även utmaningar. Kanske inte i de agila metoderna i sig, men i mötet mellan agila metoder och mer traditionella organisationer. 

• Styrgrupp/projektägare styr projekt mot mål snarare än resultat, vilket riskerar leda till en alltför detaljerad styrning som inte tar vara på fördelarna med ett agilt arbetssätt 
• Olika synsätt hos projektledaren och scrum mastern kring prioriteringar kan förekomma, ofta beroende på att ansvar och mandat inte är tillräckligt tydliga
• De agila teamen är splittrade mellan projekt och förvaltning, vilket gör att teamen inte är så självstyrande som de bör vara. 
• Rådande budgetmodell kan ibland innebära att det är svårt att planera för agila projekt där det föreligger en stor osäkerhetsfaktor

Vad kan jag som projektledare göra? Jag skulle säga: mycket mer än du tror. Faktum är att de flesta styrgruppen tacksamt tar emot stöd och hjälp kring tillämpning av agila metoder. Att ta sig tid att förklara fördelarna är därför väl investerad tid. Inte sällan har medlemmarna i styrgruppen också mandat att styra över resurser både i projekt och förvaltning och lyckas du som projektledare ge en bra bild av hur resurserna kan användas på bästa sätt, är det betydligt troligare att projektet lyckas.

Se till att det är tydligt vilket ansvar och mandat produktägare, scrum master och projektledare har. Även om det kan tyckas självklart för dig, är det inte alls säkert att det är det. Så förutom att tydliggöra vad som ska göras – tydliggör också vilka roller som ansvarar för vad. 

Sist men inte minst – dokumentera noggrant vilka mandat du har när det gäller change management – både när det gäller vad som ska levereras och vad det får kosta. Se till att det är tydligt vilka beslut du får fatta och i vilka fall du behöver eskalera till styrgrupp/projektägare. En tydlig change management ökar chansen att driva ett lyckat agilt projekt, och sparar oerhört mycket resurser både för projektledare och styrgrupp. 

En djärv lösning på detta skulle kunna vara att man som organisation slutar skapa e-postadresser per default vid anställningar. Behöver alla anställda en e-postadress, eller kan den interna kommunikationen ske genom ett internt verksamhetssystem? Kan e-postadresserna utformas på ett sätt som gör att de inte enkelt går att lista ut för externa? Går det att ersätta publicering av e-postadresser på externa webbsidor med formulär som styr direkt mot verksamhetssystem som utifrån exempelvis ämne slussas rätt i organisationen? Beroende på hur behoven och förutsättningarna ser ut är detta frågor som behöver ses över.

När e-posten väl tagits emot uppkommer ytterligare frågor. Hur länge måste jag spara e-posten, och vad gör jag med information som behöver bevaras eller information som kan vara ”bra att ha”? Rekommendationen är att man flyttar över nödvändig information till ett internt system, där man kan ange utifrån vilken grund informationen sparas. Det system man använder bör vara uppsatt på ett sätt som gör att datan lätt kan tas bort när den inte längre behövs, och naturligtvis behöver åtkomsten behörighetsstyras och loggas.

En stark rekommendation och ett minimum när det gäller att uppfylla kraven i GDPR är att en organisations e-post inte tillåts användas privat. Privat användning innebär nästan alltid att personuppgifter tas emot i onödan, vilket inte är önskvärt. Sätt istället upp rutiner för hur e-posten får användas, och styr så långt det är möjligt in kommunikationen i system som satts upp enligt ”Privacy-by-design”.

Intresseavvägning framställs lite som GDPR:s slasktratt, och exakt hur den kommer att få användas är fortfarande oklart. Jag tycker emellertid inte att den bör avskrivas, utan rekommenderar faktiskt att man överväger den innan man överväger någon annan rättslig grund. Detta eftersom den är pragmatisk utan att för den skull innebära att personuppgifter behöver hanteras på ett otillfredsställande sätt. Ifall man tillämpar uppgiftsminimering och lagringsminimering, inte hanterar känsliga personuppgifter och tydligt kommunicerar sin integritetspolicy är min tolkning att intresseavvägning bör räcka tämligen långt.

Artikel 6 (f) säger följande om när intresseavvägning får användas:

Behandlingen är nödvändig för ändamål som rör den personuppgiftsansvariges eller tredje parts berättigade intressen, om inte den registrerades intressen eller grundläggande rättigheter och friheter väger tyngre och kräver skydd av personuppgifter, särskilt när den registrerade är ett barn

som ett tillägg anges sedan att intresseavvägning inte

…ska gälla för behandling som utförs av offentliga myndigheter när de fullgör sina uppgifter.

Relativt mycket bör kunna falla in under ovanstående skrivelse, exempelvis så finns det angivet i skäl 47 att ett berättigat intresse kan föreligga vid ett relevant och lämpligt förhållande mellan den registrerade och den personuppgiftsansvarige där registrerade är kund hos eller arbetar för den personuppgiftsansvarige. Som ett exempel anger man att direktmarknadsföring kan betraktas som ett berättigat intresse, och om direktmarknadsföring anses vara ok tolkar jag det som att även en rad andra behandlingar torde vara det.

Skrivelsen som säger att berättigat intresse inte får användas av myndigheter vid fullgörandet av myndighetens uppgifter är också väldigt intressant – då det bör kunna förekomma personuppgiftsbehandling som kanske inte är en del av myndighetens ordinarie uppgifter – men som man ändå anser sig ha ett behov av? Är ”myndighetens uppgifter” att betrakta som myndighetens kärnverksamhet, medan i så fall viss behandling rörande exempelvis anställda skulle kunna få hanteras som ett berättigat intresse? Borde man inte annars ha uttryckt sig kort och gott med: ”ska inte gälla för behandling hos offentliga myndigheter”?

Så innan din organisation påbörjar ett omfattande arbete med att samla in samtycken och kanske till och med köper in ett systemstöd för att administrera samtycken – överväg om inte intresseavvägning kan vara en gyllene medelväg!

Ett registerutdrag ska innehålla alla personuppgifter som rör den person som söker ett registerutdrag, varifrån dessa uppgifter kommer, vad som är ändamålet med behandlingen, till vilka mottagare eller kategorier av mottagare uppgifterna lämnas ut och om möjligt under vilken period uppgifterna kommer att lagras (artikel 15).

Jag har ägnat en del tid åt att kontakta organisationer i syfte att ta reda på hur registerutdragen kommer att hanteras efter den 25 maj – och resultatet är, tycker jag, väldigt intressant. Till att börja med kan sägas att de flesta jag varit i kontakt med tycker att deras egen tolkning är ganska självklar och man har generellt ägnat ganska lite tid till omvärldsbevakning och att fundera över vad artikel 15 egentligen säger. Man kan i huvudsak säga att det finns två tolkningar:

1. VI LÄMNAR UT ALLT
   Kategori 1 har tolkat artikel 15 som att allt rörande en person ska lämnas ut. Här ingår alltså inte bara  personuppgifterna i de register som organisationen hanterar, utan även de handlingar i vilka personuppgifter förekommer. För exempelvis en myndighet, eller annan offentligt organisation, kan detta innebära väldigt mycket uppgifter. En person kan förekomma i ärenden med en stor mängd olika handlingar, handlingar som förutom de egna personuppgifterna kanske också innehåller uppgifter om andra personer som ingår i ärendet. Vad gör man då med de personuppgifterna? Här finns flera olika tillvägagångssätt – somliga tänker sig att uppgifter rörande andra personer ska raderas, medan andra har en annan tolkning och har för avsikt att lämna ut handlingarna i sin helhet (om de inte omfattas av annan sekretess). I det senare fallet rör det sig uteslutande om offentliga organ som är vana vid att hantera utlämnande av allmän handling. Organisationer inom kategori 1 väntar på en anstormning av utlämnanden, och diskuterar i termerna att de kommer behöva lämna ut hundratals papper vid varje begäran.
2. VI LÄMNAR BARA UT REGISTERUPPGIFTER
   Kategori 2 har tolkat samma artikel som att det enda som behöver lämnas ut är de register, i vilka personuppgifter förekommer. Detta skulle exempelvis kunna innebära att man tillhandahåller diarieuppgifter, men att man inte tillhandahåller tillhörande handlingar. Om en person sedan önskar ta del även av handlingarna får denna återkomma med ytterligare en begäran (som hos offentliga organisationer då oftast tolkas som en begäran om allmän handling, vilket även genererar möjligheten att ta betalt för de kopior som lämnas ut).

Sen finns ytterligare frågetecken som är oberoende av ovanstående tolkningar. Några organisationer har fäst stor vikt vid hanteringen av ostrukturerad data och har satt begränsningar kring hur e-post och gemensamma filytor får användas i syfte att få kontroll över hur personuppgifter hanteras. Andra har valt att till en början fokusera på den strukturerade datan. Någon organisation har funderat över om uppgifter som loggas vid olika typer av åtkomst utgör registeruppgift och därför ska lämnas ut? Och hur ska man se på backuper? Kan en uppgift anses som raderad när den tagits bort i ett verksamhetssystem, även om den fortfarande finns kvar i en backup – kanske i flera år? Och hur söker vi i så fall reda på uppgiften när någon begär ut ett registerutdrag?

Hur ser din organisation på registerutdrag? Vilka utmaningar har ni råkat på?

Men oj vad arbetet visar sig vara omfattande! Vi fastnar i detaljer och någon föreslår att vi kanske skulle kunna göra på något annat sätt. Kanske skulle vi ändra ordning och bryta ner arbetet i mindre delar? Kanske är något vi tidigare inte tänkt på viktigare? Nej, vi kör på som vi bestämt – allt måste kartläggas!

Och självklart vore det bra om allt var kartlagt så att vi enkelt kunde redogöra för våra processer och vilken data vi har i våra system den dag Datainspektionen knackar på dörren. Men till vilket pris? Vad är det vi tvingas prioritera bort? Att ta fram strategier för ”privacy by design”, nya rutiner för ostrukturerad data såsom e-post och att göra medarbetarna medvetna om det ansvar som följer med GDPR? Delar som kan vara minst lika viktiga.

Så gör det agilt! Ställ er frågan vad som är viktigast just nu. Var lyhörda för vad som händer under arbetets gång. Hur gör andra organisationer? Är den valda inriktningen fortfarande relevant? Eller borde riktningen justeras till förmån för något som visat sig vara viktigast i organisationen just nu? Och glöm inte att utbilda medarbetarna – de är nyckeln till framgång!

Om ni är nyfikna på att höra mig prata om GDPR och vad som är viktigast för organisationer som är sent ute, är ni välkomna till MyOffice i Örebro den 16 maj kl 9.00. Anmälan till den kostnadsfria frukostföreläsningen görs här!