Kravbloggen

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?

Har ni hört talas om "filterbubblan" när det kommer till sociala medier och sökningar på internet? Kort sammanfattat kan man säga att det som presenteras i form av sökresultat och nyhetsflöde numera alltid har filtrerats och personifierats utefter dina (outtalade) preferenser. På det personliga planet har vi motsvarande mekanismer, där hjärnan kortsluter och försöker hitta enkla sammanhang som styrker redan tillskansad kunskap.

För några år sedan sa en kollega till mig att "en expert som bara förlitar sig på sin expertis, förlorar i det långa loppet mot en novis som drar nytta av sin omgivning".

Jag har burit med mig detta och försökt att omvandla det till ett förhållningssätt rörande både min och andras kunskap - även när man tror att man vet allt så gör man inte det.

Det går inte att fråga en användare vad hen vill ha när det kommer till IT stöd för verksamhetsprocesser.

Varför inte?

• Ofta får man inte de stora penseldragen och de mer strategiska perspektiven från en slutanvändare. Det blir lätt att man cementerar dagens sätt att arbeta då man har svårt att lyfta blicken.
• Det kan lätt bli lite för mycket "läppstift på grisen" alternativt att man suboptimerar outputen utefter specifika behoven. Man tar helt enkelt inte in helheten i beräkningen när man tittar på var man ska lägga sitt krut. Vad är affärsvärdet för att implementera en viss feature kontra en annan?
• En slutanvändare kan också ha svårt att artikulera vad det är man vill ha. För att ta ett klassiskt T-Ford exempel: Om du hade frågat vad folk ville ha så hade de sagt "snabbare hästar", när deras egentliga behov var snabbare transporter.

Självklart menar jag inte att man ska stänga ute slutanvändaren, men ibland blir jag lite provocerad av bilden att de sitter på hela sanningen. De ska vara med och forma lösningen men på ett balanserat sätt.

Så vilka kompetenser behöver vara med för att vi ska göra rätt saker och få ut rätt output?

Det finns två uppgifter som man som kravanalytiker måste förhålla sig till. Den första är det dagliga arbetet med att ta fram krav på de behovsställningar som finns i verksamheten. Den andra är att sätta formerna för hur kravarbetet skall bedrivas. Den senare är en förutsättning för att den första skall kunna göras så effektivt som möjligt och till ett bra resultat.

Hur man arbetar med krav skiljer sig från verksamhet till verksamhet beroende på förutsättningarna som ges. Fler känner förmodligen till rollen kravanalytiker än de som fullt ut förstår hur man arbetar och vilka förutsättningar som krävs för att kunna leverera en bra och fullständig kravställning. Hur man kommer att kunna arbeta i rollen beror därför mycket på sammanhanget man hamnar i. Mognad och erfarenhet av att arbeta med förändring i en verksamhet samt övriga rollers uppdrag och ansvar är några avgörande för faktorer.

Oavsett utgångspunkt är det många roller som behöver involveras i kravarbetet och som behöver få en förståelse för vad de ska bidra med och på vilket sätt. Men det gäller även att skapa utrymme för de aktiviteter som från ett kravperspektiv behöver genomföras i initiativet.  Att reflektera och planera för dessa två är viktigt för att kunna skapa förutsättningarna för ett bra kravarbete.

Det är alltid en utmaning som kravanalytiker att säkra att man fångar alla aspekter nödvändiga för den lösning som skall tas fram eller att inte förlora momentum i kravarbetet.

Elicitering, eller kravinhämtning som det också heter, handlar just om den del av kravarbetet som syftar till att få fram olika intressenters krav, väga dessa gentemot varandra, för att till sist kunna presentera en sammanhållande kravbild. Den som arbetar med krav har dock många gånger fått erfara att de involverade kan ha skilda uppfattningar kring det område i verksamheten som är föremål för en förändring.

Det är också viktigt att som kravanalytiker hålla engagemanget uppe bland de som deltar i kravarbetet. Haltar de inledande diskussionerna och tiden drar ut utan att man lyckas uppnå något resultat, riskerar man att förlora intresse och fokus bland dem man är beroende av.

Att skapa en samsyn är därför A-O för att få igång arbetet på ett smidigt och smärtfritt sätt. Processer är då ett bra sätt att skapa en gemensam bild av verksamheten utifrån vilken kommande diskussioner kan ta sin utgångspunkt.

Under en av våra AWs på Require pratade Tobias Nilsson om möten och problemen med att få folk att gå på dem. Han lekte då med titeln på anförandet "Ingen kommer på mina möten" som med en bokstavsändring blev "Ingen kommer på sina möten".

Inför arbetet med Kravdagen 2017 satt jag och bollade uppslag till tal med en av anförarna och fick följande förslag "Att ställa krav är att bry sig".

Båda dessa uppslag pekar på något man ganska ofta hamnar i som kravhanterare, verksamhetsanalytiker, eller processledare - folk tror att man jobbar efter egen agenda. När man i själva fallet jobbar för någon annan och där denna någon i många fall är den som ska ställa kraven och komma på möten.

Det händer lite nu och då att någon lägger upp en bild på Linkedin med ett citat av Oren Harari som säger ”The electric light did not come from continuous improvement of candles”. Det ska tydligen vara något sorts statement mot agila metoder och specifikt då Continuous Delivery antar jag. Det blir en hel del delningar och ”Spot on”-kommentarer varje gång den dyker upp. Själv blir jag lika förvånad varje gång, både att folk delar ”tänkvärda citat” på Linkedin men också att folk håller med när citatet ju faktiskt missar målet fullständigt.

Arbetet med att ta fram en lösning på ett behov eller problem involverar ofta många personer, alla med olika ansvarsområden, kompetenser och uppgifter. I en processorienterad verksamhet samverkar dessa för att uppnå ett resultat, där var och en bidrar med sin del utifrån hur behov, krav och lösning ser ut.

Likväl talar vi ofta när det kommer till krav om överlämning av dessa mellan olika roller i initiativet. Detta är något som skapar ett problem eftersom det i begreppet överlämning lätt tolkas, medvetet eller omedvetet, som att man överlåter ansvaret för dessa till någon annan. Risken blir att man som kravansvarig tar ett steg tillbaka och väntar på att en lösning skall presenteras eller få ett kvitto på att beställaren är nöjd. Inget kan vara mer fel!

Igår hade jag möjligheten att prata på Requires After Work. Jag berättade om likheter och olikheter som jag har upplevt efter att ha jobbat med krav i över 15 år inom olika branscher.

Den mest slående likheten tycker jag är att det ALLTID är BRÅTTOM.

Som konsult ligger det lite i sakens natur att det är bråttom eftersom man tar in konsulter när man saknar tid eller kompetens att göra något själv, men att det är bråttom gäller inte bara när jag arbetat som konsult. Ofta är det också brist på förståelse för "VARFÖR TAR DET SÅ LÅNG TID". 

Har precis läst ut boken ”Lean from the Trenches” av Henrik Kniberg. En lättläst bok om hur de jobbade i ett stort projekt med 60 projektmedlemmar på Rikspolisstyrelsen.

Henrik beskriver hur de kombinerade XP, Scrum och Kanban. Boken tar upp vad som fungerade, vad som inte gjorde det, varför och hur processen utvecklades.

Det beskrivs hur de arbetade praktiskt genom hela utvecklingsprocessen. Jag tycker boken blir levande genom verkliga exempel och massor av  foton på t.ex. deras fysiska Agila tavlor.

Jag blir så glad över att läsa om ett projekt där man tillsammans arbetar fram ett sätt att jobba effektivt ihop. Hur man gör stora förändringar genom att låta små förändringar i samma riktning ske ofta.

Samtidigt funderar jag på om hur det känts om jag hade varit med i projektet. Henrik var inne i projektet ett halvår och det är det halvåret som boken beskriver. Det måste ha varit mycket stimulerande och intensivt att vara med och förändra projektet tillsammans.

Men vad händer sedan.

När vi pratar om krav och kravarbete kopplar man oftast detta till arbetet med att ta fram en specifikation som skall ligga till grund för en lösning och acceptans av denna. Men det finns ett annat perspektiv som inte alltid får samma fokus men som är av stor betydelse. Nämligen att ta fram ett väl underbyggt beslutsunderlag för att säkra att man arbetar med rätt behov.

Jag menar att för varje behov man arbetar med att förverkliga så finns det tre frågeställningar som behöver besvaras för att just säkerställa detta, nämligen;

• Är behovet relevant?
• Finns det ett business case?
• Efter detaljering, håller Business case:t?

Svaren på frågorna får man fram genom att arbeta iterativt med behovsställningen, dvs genom att bryta ner behovet får vi mer kunskap och insikt och därmed bättre förutsättningar för att både värdera behovet i sig men även sätta det i förhållande till andra. Utgångspunkten är att säkerställa att man hela tiden arbetar med de behov som genererar mest affärsvärde och samtidigt få en förståelse för vad det medför att förverkliga det.

Låt oss titta närmre på var och en av dessa och vad de tillför! 

Vi är Linus Lundahl och Fadi Rabah, två studenter från Nackademin som gör sin LiA period på Require AB. I september gav Require oss den fantastiska möjligheten att delta i Mastering the Requirements Process, en tredagars kurs ledd av Suzanne Robertsson. I det här inlägget presenterar vi våra reflektioner efter kursen.

Volere – italienska för att önska eller vilja. Ett ord Suzanne ofta återkommer till i kursen. Volere är också namnet på ett koncept framtaget av Suzanne och James Robertson som omfattar framtagandet, kommunikationen och hanteringen av krav. För oss är det inte möjligt att helt sammanfatta dessa tre dagar i ett blogginlägg, med tanke på vilket gediget material kursen består av. Alla deltagare tog säkert med sig olika tankar, idéer och verktyg när de gick hem efter kursens slut – men här nedan följer våra tankar och intryck av kursen, och av Volere.