Kravbloggen

Under en lunch för inte så länge sen hamnade jag och en kollega i diskussionen om paragrafryttare, de som ska följa varenda liten skrivelse i ett ramverk konstant för att annars ’bryter vi mot ramverket’. Under konversationen sa jag att eftersom jag är en person med ’regler är till för att brytas’-mentalitet, kan man väl säga att jag har väldigt svårt att klicka med personer som alltid ska ha regelboken i högsta hugg och vägrar tumma på linjen.

Så kom frågan, ’Men Kattarina, du är ju kravanalytiker, du skriver ju krav som i princip är regler, hur går det ihop?’ – Jo det ska jag försöka svara på.

I mitt senaste projekt jobbade jag som kravanalytiker i ett stort agilt team tillsammans med ett gäng utvecklare, testare och UXare. Vi alla var nya i teamet och vi alla var lite osäkra på våra olika ansvarsområden. Framför allt mellan mig som Business Analyst (BA) och UX. Var går egentligen gränsen mellan vad en BA hämtar in för krav och vad en UXare hämtar in för krav? Visst känns det ibland som om rollerna överlappar varandra?

Jag har haft möjligheten att jobba med Microsofts PowerApps. En fantastiskt rolig och förhållandevis enkel möjliggörare för att få ut saker snabbt. Den har dock sina begränsningar.

Under ett av mina uppdrag hamnade jag i ett väldigt intressant och lärorikt sammanhang – jag reflekterade mycket över detta projekt och hur vi gjorde saker och när jag beskrev det för mina kollegor insåg jag ännu mer hur unik denna erfarenhet var.

Det finns en omtalad studie på schimpanser från 60- eller 70-talet som ibland återges i olika sammanhang. I studien släpps 20 schimpanser in i en stor sal som är tom så när som på en stege och en klase bananer som hänger strax ovanför stegen. Det dröjer inte länge förrän några schimpanser upptäcker bananerna och sätter av mot stegen. Så snart den första schimpansen tar tag i stegen duschas hela salen i iskallt vatten. Chockade av denna djupt obehagliga upplevelse faller alla aporna till marken.

Efter en stund repar sig de flesta och ytterligare en gång beger sig ett par av schimpanserna mot bananerna. Så snart stegen vidrörs upprepas samma iskalla dusch av alla schimpanser och nu är det några apor som ser en koppling mellan att vidröra stegen och att få en kalldusch. Det gäller dock inte alla, och en av de som inte förstått hur det hänger ihop sätter av mot stegen.

Jag är ingen psykolog och har inte studerat heuristik akademiskt men jag har jobbat i drygt tjugo år på olika sidor av ”bordet”, presenterat saker i olika forum, bett andra ta beslut, varit den som tagit beslut och funderat på hur saker ska vara. Och det har fått mig att reflektera över varför man ibland tänker, tycker och beter sig som man gör som individ, i grupp och mot individer/grupper.

En återkommande och vanligt använd teknik för att hitta en rotorsak är ”5 Varför”. Tekniken baserar sig på att man fem gånger frågar efter varför ett fel har uppstått, och genom det kan man hitta rotorsaken till felet.

I denna blogg redovisar vi resultatet av en enkät där vi ställde frågor till våra konsulter rörande Beroende – vilka typer av beroenden ser vi på våra uppdrag, hur påverkar de det dagliga arbetet, och hur hanteras de?

Vet ni skillnaden mellan korrelation och kausalitet?

• Korrelation – Om det finns ett samband mellan två eller fler faktorer säger man att de korrelerar. Korrelation innebär inte nödvändigtvis att det finns ett orsakssamband (kausalitet). De kan båda vara påverkade av en tredje faktor eller så kan sambandet bero på slumpen. 

När vi ska byta bostad måste vi planera, samla och gå igenom våra behov och besluta oss för vad vi ska ta med i flytten och vad som eventuellt måste justeras i den nya bostaden innan flytt.

När vi byter från ett system vi arbetar i till ett annat ställs vi inför samma typ av frågor; vad ska vi ta med, vad kan vi lämna kvar och vad behöver vi modifiera?

Du har din bostad som du känner så väl och kanske en hel del saker i skåp och lådor som du sällan eller aldrig använder. Ska du ta med dig dessa till den nya bostaden eller ska du lämna kvar (sälja eller ge bort) dem. När du står inför flytt av system kan det vara dags att titta på din data och datamodell, flytta inte en röra utan strukturera upp så du får bra datakvalitet i ditt nya system och kanske kan du även här rensa bort en del som inte används.

När du lagar mat ökar dina chanser att rätten som du håller på att laga blir god och tilltalande genom att du följer ett recept. Ett bra smaksinne samt att du har instinkt för smaker och en visuellt konstnärlig ådra kan också bidra. Men matlagning i en perfekt miljö där inget oväntat händer eller en kock som lagar mat utan recept eller kunskap, med enbart rå talang är ganska unikt. Jag skulle inte anlita en sådan kock. Skulle du?

Så vad är det vi letar efter? Är det inte erfarenhet?

I många fall behöver inte erfarenhet vara något som en specifik individ innehar och den behöver inte vara självupplevd. Erfarenhet kan vara kollektiv.

Som du kan se nedan, i min kategorisering av punkterna, så är det upp till dig men också din organisations / teams / nätverks ”ansvar” att skapa och ta till sig dessa erfarenhetskomponenter.

Så vad är erfarenhet, enligt mig?

För ett tag sedan lyssnade jag på avsnittet ”Om Expressensvenskan” i podden ”Snedtänkt” med Kalle Lind. Det fick mig att fundera om vi som verksamhets- och kravanalytiker kan lära oss något från ”expressensvenskan” för att bli tydligare i hur vi uttrycker oss?

Som konsulter kommer vi in i vitt skilda verksamheter med uppdraget att analysera ett nuläge och få någon form av förändring till stånd. I samband med Corona-pandemin har vi tagit tillfället i akt att se över vår egen verksamhet med hjälp av metoder som vi använder i uppdragen.  

I våras byggde vi trall och terrass här hemma. Under arbetes gång blev det uppenbart för mig hur mycket likhet detta bygge hade med agil mjukvaruutveckling. Flera koncept som jag precis läst om under min SAFe-certifiering tillämpades i praktiken.

När är det värt mödan att ge sig på en förändring och den resa det ofta innebär?
- Det är när det är din inom "my business”.

När man lagar mat behöver man veta vad det är man vill uppnå, vad som är viktigast och förstå situationen man står inför. På samma sätt är det med jobbet som verksamhetsanalytiker / kravhanterare. 

Sammanhanget som du är i och situationen du står inför måste påverka hur du tar dig an din uppgift. Att använda samma metoder, verktyg och angreppssätt oavsett kontext kommer ge dig, alternativt din uppdragsgivare, huvudvärk. Inget uppdrag är det andra likt och detta behöver man acceptera och anpassa sig efter. 

Robert started this series with Let’s go “all in”! And in that blog post he mentions going all in without questioning, without adapting to your abilities, context or without applying some common sense. 

Common sense is something people often use to value other people’s actions and behaviors. Completely disregarding their own behaviors. Or rather, Common sense for them is a projection onto others as something that should be applied in all situations. As if that would be a miracle cure.

But what is common sense? 

This is the definition of “common sense” according to dictionary.cambridge.org: 

 “The basic level of practical knowledge and judgment that we all need to help us live in a reasonable and safe way”. 

De flesta av oss har lärt oss att sträva efter att vara effektiva på jobbet. Att implementera processer är en del av den strävan. Processer reducerar risken i en organisation, men varje lager av processer reducerar också förmågan att vara agil och lean, och kanske framförallt förmågan att vara anpassningsbar till möjligheter och hot.

Men i en snabbt föränderlig värld där vi inte längre kan förutspå framtiden och prognoser inte håller så borde fokus skifta till flexibilitet och motståndskraft.

Med tanke på ovanstående, så skulle jag vilja påstå att vi helt enkelt inte längre ska ha effektivitet som ledstjärna och ett mål att sträva efter. Det kanske till och med är tvärtom?

I mitt tidigare yrke utvärderade jag kompetenser i relation till deras yrke och i mötet identifiera eventuella funktionsvariationer genom en dialog med personen i fråga. Det var en nödvändig analys för att kunna bedöma vilken insats som behövdes i nästkommande anställning. Att hantera människor med olika typer av funktionsvariationer kräver en viss kompetens som jag erhöll i mötet med kunderna men även genom internutbildningar av psykologer. Lärdomar om människors kroppsspråk och känslouttryck för att förbättra min egen kommunikation har varit ovärderliga insikter.  Efter tio år i yrket har jag mer än 8000 arbetstimmar i dialog med kund, där jag behövt applicera dessa kunskaper i varje enskilt möte. 

Jag beskriver arbetstiden för att ge dig som läsare en bättre bakgrund av min yrkesnivå och kunskap av människors dagliga kamp i den utsatta situation som det innebär att inte längre upprätthålla Status Quo i form av en anställning.

In December last year I had the fortune to become part of a development team. The last few years my position haven’t “allowed me” to work in a team set-up, that a scrum team embodies. I came to realize how much I’ve missed it! The social aspect and the support that a team really creates became obvious to me.  

The Need to Belong 

The Need to Belong is the strongest one of the drives and the easiest (relatively speaking) way to drive a person forward to the end goal and success.  It might sound simple (common sense) when you read it to understand that we are social animals and thus want to belong to other humans that we feel that we belong to.  

But what is the downside of this human drive?  

Well, ask yourself these questions: 

• Will the team members question the team manager or others within the team?  
• Will they “question status quo” if they feel something is skewed or off?  

Well, this drive hampers that possibility. Since questioning might put you outside of the group and working against the need for belonging.  

Robert summoned it up very well in that we tend to go all in and soon thereafter fail in a grand way.  Don’t get me wrong. I would argue that it is good to fail, and people do that every day as a part of everyday life. If I am not mistaken, Google admits that they fail nine times out of ten.  

Do not forget that you daily fail in repetitive tasks that you thought you already did perfectly. And that’s because you're human. Humans are not robots. 

Through failure we find understanding about what works in what we currently are testing out. That is true even when quitting a use of a drug. We try and try again to quit smoking. Most people succeed. 

So, what is it that Robert is talking about? 

A new year and with that comes New Year´s resolutions! The ultimate “Challenge Status Quo”! 

"2020, THIS will be the year that I will … "

... and then you go “all in” with the ambition to c

hange “everything”. But by March you have lost your stamina and you are back doing what you’ve always done. Does that feel familiar? 

I can see similarities to how business initiatives are approached - It’s quite often that you go in with an “all in” approach, things should be by the book full steam ahead, and less consideration is done to the specific context and common sense is easily left aside.  

So, why do we do this?  

Have you ever felt like your company is going nowhere with its IT development or struggling to pick up pace? Have you had a frustrating conversation with coworkers about the topic, “Why are we not moving forward more quickly? “. Well, it might just have to do with a number of mental models that humans create in their own head to make the person more effective throughout the day. 

Thus, the known expression “It is hard to teach an old dog to sit! “.

Ni har väl hört uttrycket – man äter med ögonen? Maten ska inte bara smaka bra den ska också se god och tilltalande ut för den som äter den. Ibland glöms just detta bort.

Om jag ska göra en köttfärssås till min 7 åring så har jag i massor med grönsaker, men min erfarenhet säger mig att för att undvika diskussioner kring vad som är i och istället ha fokus på hur god den är så mixar jag grönsakerna. Jag anpassar min presentation till målgruppen så att fokus hamnar rätt.

På samma sätt är det med krav - bara för att informationen finns där och till och med är rätt så betyder det inte att den visas upp. Både detaljeringsnivå och syntax bör anpassas, då både målgrupp och mognad/tidpunkt spelar en roll i utformningen.

As a buyer of a new system we formalize our expectations on the solution we want with functional and non-functional requirements. We also make sure that the new vendor is compliant with all our standards and values and that they have good credit rating and great references. And of course the price as an offer you cant refuse offered by a very nice salesperson. But what about the relationship between the two soon-to be-partners? I have been working with procurement for both sides - the vendor and the buyer - and both take for granted the upcoming collaboration will be smooth. It is often not and soon the blame game is on. So why don’t we set the expectations on eachother ways of working as partners, instead of vendor/buyer, early in the RFI so we mitigate the risk of project failure?

För mig är det en stark drivkraft att förstå hur min insats har påverkat ett initiativ, såväl utifrån projektets framdrift som den slutliga lösningen. Med det som utgångspunkt försöker jag se hur jag kan förbättra mitt sätt att arbeta som kravanalytiker. 

Tobbe: Jag vill ha en syltbulle!

Robban: Va?

Tobbe: Jag vill ha en SYLTbulle!

Robban: Är du hungrig??

Tobbe: Mmmm... kan inte du SNÄLLA gå och köpa en på Fabrique? Jag swishar!

Foto av Staff Sgt. Michael Battles

Nyligen hjälpte jag en startup med kravhantering. Det gick inget vidare då chefen ändå smög in brådskande nya features på post-it lappar och jag kunde inte förstå varför teamet jobbade sena kvällar.

Före det hjälpte jag ett 100 årigt gediget svenskt tjänsteföretag med att, bland annat, coacha produktägarna. Det gick heller inget vidare då produktägarna inte hade tid och behövde sköta sitt riktiga jobb.

Så vad förenar dessa två helt olika organisationer om vi håller oss till krav? Jo, bägge företagen fuskade grovt med flera rubricerade dimensioner av krav (och en hel del annat) och här är min spaning hur dessa kan skapa ett fundament för bra krav. (Givetvis har jag feedbackat detta till respektive företag men det tål att tas upp igen.)

På pappret är produktägarskapet väldigt enkelt – maximera affärsvärdet av ett teams arbete. VAD ska göras och NÄR. I verkligheten är detta inte fullt lika trivialt. Även om man föresatt sig att jobba agilt så finns det ofta faktorer som stör en strikt prioritering helt efter affärsvärde – beroenden till andra team, kunskaper hos olika teammedlemmar med mera. Jag skulle vilja dela med mig av är några tips kring hur man kan agera som produktägare.

På Kravdagen 2019 kommer vi under programpunkten Speakers Corner att bjuda in till tre olika diskussioner om Roller, Metoder och Krav. På temat "Vad kan man kräva av Krav?" kommer jag att tillsammans med dig och andra kravintresserade att diskutera olika infallsvinklar och uppfattningar kring begreppet Krav.

Något jag tycker mig se som ett återkommande mönster i många av de IT-projekt jag arbetar som kravare i, är vilken extrem tilltro vi tillskriver metoden. Använder vi oss bara av de vedertagna och framförallt moderna metoderna så kan det ju inte gå fel. Men används metoderna för att gynna vårt sätt att arbeta och ta beslut på eller för att det helt enkelt ”är så man gör”? Klart vi inte skulle erkänna att vi bara följer strömmen, men ibland får jag känslan av att vi ändå är rätt dåliga på att utvärdera det arbetssätt vi använder. Några exempel nedan.

Bilden ovan är målningen De Kwakzalver gjord av Jan Steen.  Bilden är fri för användning på Wikimedia commons

Den frågan ställer jag mig då det är tre roller som jag har verkat inom men som jag nu märker blivit överflödiga, och därmed också jag, likt maskinskriverskor, rallare och kvacksalvare*? Jag har väl 10 år kvar i branschen, men kan jag hänga kvar alla dessa år när yngre hungriga talanger, med coolare och kryptiska titlar som tex RTE och med certifikat som utklassar mitt CV. Och efter något år i rollen lägger de till prefixet senior och dubblar sin lön. Och nu ska de nu höja pensionsåldern till råga på allt. Brandmän och balettdansörer får ju gå innan 60 så vore det inte på plats att överflödiga IT-konsulter som jag får göra det också?

"Tre blinda män skall tillsammans köpa ett dragdjur och blir presenterade för en tapir.

Den förste tar på snabeln, den andre klappar på sidan och den tredje tar tag i svansen.

Efter en kort diskussion konstaterar de gemensamt att djuret de mött måste vara en elefant. De bestämmer sig för att djuret uppfyller deras krav och de slår till på ett köp då de får den till ett vad de tycker är ett bra pris.

När djuret senare levereras inser männen att elefanten de köpt är en tapir vilket såklart inte alls motsvarade deras behov."

Alla har vi varit där. På konferenser och på kurser, på teambuildingaktiviteter och kick-off. Nu ska vi äntligen få lära oss en ny och användbar metod från branschens just nu klarast lysande stjärna. Inte nog med det, vi ska ha kul på kuppen!

Men, hur bra är den enskilda metoden egentligen? Är den rentav skadlig!?

Folksagan om Mäster Skräddare är ett underbart exempel på hur en beställning inte ska beställas, hur ett projekt inte ska genomföras och hur en leverans inte ska levereras – med andra ord hur en verksamhet inte ska bedrivas hur och en kundrelation inte ska hanteras.

Rubriken skulle också kunna vara ”Är Produktägaren vår Superhjälte?” eftersom produktägaren såsom jag känner rollen måste vara en mångkonstnär av rang samtidigt som produktägandet ska kombineras med andra åtaganden. Låt gärna bilden av Superhjälten vila i minnet medan du funderar på hur många Superhjältar du mött så kan vi återkomma till den bilden lite senare.

En sak som jag har funderat över är att det är så effektivt att jobba fram krav och lösning tillsammans i grupp med olika discipliner representerade och att arbetssättet ändå så ofta ifrågasätts. Mycket av ifrågasättandet handlar om att det tar mycket tid från många resurser. ”Behöver ni verkligen sitta tillsammans hela tiden” och ”kan ni inte dela upp jobbet”.

The Swedish academy is the governor of the Swedish language but when you search for the word agile in their online dictionaries you get no hits. I heard it takes twenty years for a new word to get added. Not so agile.

But if you search for the word resource you get hits explaining the meaning as opportunity or way out, often in the context of financial assets. This post is about the words that we can stop using and which to start use instead, so we understand each other better, for instance, the awful word resource.

GDPR, eller The EU General Data Protection Regulation, som den också kallas för. Den har ni inte missat, va? Om ni tror det handlar om en ny viktminskningsmetod så här inför sommaren, så kan det vara dags att börja googla efter ”GDPR” och se vad det egentligen handlar om. Men, du får vara lite kvick nu, för den 25/5 börjar den gälla. För alla företag, stor som pytteliten.

Vad kan vi lära oss från matlagning? Precis som vid kravhantering och programutveckling kan man tillämpa olika tekniker och ”best practices”.

På de flesta företag finns processer för hur kravarbetet ska utföras. Vad som ska göras, när och på vilket sätt. Ofta används en agil approach och ibland kombineras det med en projektstyrningsmodell. Som ”kravare” har man också ofta flera arbetssätt i sin verktygslåda. Allt från det klassiska upplägget med Elicitation, Analysis, Specification och Validation, till User Stories, Use Cases 2.0 och Volere. Det finns med andra ord gott om arbetssätt och metoder beskrivna, och som kravare vet man vad som är viktigt för att resultatet ska bli bra.

Det var bara det där med verkligheten.

Nudging är ju hett i dessa Nobel-dagar. Börjar man läsa om det yttrar det sig i många olika former och situationer. Nudging är en gren inom beteendeekonomi som handlar om hur man kan påverka människors beteende genom att arrangera en valsituation. Och vi som är verksamhets- och  kravanalytiker är inte undantagna enligt mig.

Sällan är vår enda uppgift att bara dokumenterar ner vad andra tycker och tänker. Ofta handlar det också att på ett pedagogiskt sätt presentera argument till olika beslut; det kan vara allt från ett business case, en plan, alternativa lösningsförslag, mockuper, etc.

Oavsett så finns det definitivt en dos av nudging. För beroende på hur vi presenterar det vi vill få fram så kommer mottagaren skapa sig en uppfattning baserat på just formatet och dispositionen. Det är viktigt för oss att vara medvetna om detta beteende då vår roll ibland ska vara neutral och ibland vill vi rikta vårt budskap i en given riktning.

Har du någon gång lyssnat på en riktigt inspirerande presentation på jobbet? Sannolikheten är tyvärr inte så stor. På en arbetsplats hålls många presentationer, men de flesta är ganska ordinära. Hur brukar du tänka och känna efter att ha varit på en presentation? Antagligen är du trött. Entusiasm? Nja…

Varför ser det ut så här? Det blir helt enkelt inte prioriterat. Framförallt tror väldigt många att det inte är så viktigt med bra och intressanta presentationer. Det räcker väl med att skriva ner det som ska sägas i PowerPoint och sedan säga det? Varför lägga extra tid på något sådant?

Under min första sommar med min blivande fru så skulle jag imponera med att fixa midsommarmiddagen. Hon skulle komma över till mig efter jobbet runt klockan 15 och sedan skulle vi ut på stan. Jag hade fixat sill och alla tillbehör och dukat upp ett magnifikt sillbord med olika sorter både på sill och nubbe. Efter första nubben undrade jag varför det inte smakade? Du gillar väl sill? Och nubbe? Jodå, det var helt OK men sen berättade hon att hon hoppat över lunchen och hade sett fram emot någon biff eller pasta. På midsommarafton, allvar!? Gungan i bilden ovan här var ordet "midsommarmiddag" som vi tolkade på olika sätt.  Då insåg jag värdet av att prata så att man förstår och sedan dess berättar jag för henne alla ingredienser i maten innan jag tillagar den.

”Beskriv dina behov och inte en lösning! Det är vi som ska komma på lösningen” är något som man kan höra rätt ofta från en frustrerad kravhanterare eller systemarkitekt.

Det finns nog ett par olika anledningar till att man enkelt hamnar i den situationen när IT och verksamhet diskuterar framtida initiativ. En är att det oftast är enklare att uttrycka sina behov via en lösning eftersom man också har idéer på hur lösningen ska se ut. Att sedan öppna upp för en annan lösning än den man sett framför sig kan både kännas riskfyllt, skrämmande, och framförallt blir ju lösningen då någon annans.  Detta skapar ofta ganska mycket friktion. Att envist basunera ut att man ska hålla sig borta från lösningen är kanske inte de pedagogiska knepet att ta till i dessa lägen och det är heller inte helt rätt (enligt mig).

Jag hade möjlighet att besöka Almedalsveckan för några veckor sedan och fokuserade lite på seminarier som handlade om upphandling i olika former. Klart intressanta och välbesökta!

Medan jag ömsom lyssnade och ömsom la mig i debatten lite grann, så reflekterade jag lite och nu undrar jag såklart om det finns någon som sysslar med upphandling i någon form som läser detta och håller med / inte håller med om mina spaningar?

Har du barn? Eller har du varit ett barn? Eller du kanske fortfarande är ett barn?

Någon av dessa frågor bör du ha svarat ”ja” på och då har du kvalificerat dig för att läsa vidare i texten nedanför. Om du svarade ”ja” på alla tre frågorna, så har du allra störst förutsättningar för att snart kunna glänsa på jobbet nästa du gång du ställs inför ett knivigt problem.

Det är inte bara sommarens efterlängtade semester som snart kör igång – det gör även pendeltågen på den nya Citybanan i Stockholm. Det är med spänning vi väntar på att se hur rätt det blev. Kommer stationerna ha "god orienterbarhet" och "gångvägar ska kännas naturliga" och har man lyckats "undvika prång och dolda hörn"? Och kommer dörrarna på plattformen att öppnas när tågets dörrar öppnas, och sen stängas när de ska? Det är en riktig nagelbitare för många.

Så var den utmanande rubriken vi, ett antal förespråkare av agila processer, ställde för tio år sedan på vår inbjudan till paneldebatt på temat. Undertiteln var Rallare, kittelflickare och maskinskriverskor och nu projektledare. Lokalen var till 90% fylld av oroliga, uppretade eller bara nyfikna projektledare och de resterande var vi fem som arrangerade. Då var vi fortfarande lite blöta bakom öronen när det gällde agilitet, som då var något katten hade släpat in i källaren medan den övriga organisationen fortsatte göra som de alltid hade gjort. Kvällen slutade i alla fall med hyfsad enighet om att rollen som sådan var på väg att förändras till förmån för mer självgående strukturer. Jag vill minnas att sista ordet den kvällen var att det alltid kommer behövas dagisfröknar.

Så vad hände sen?