Dags att överge begreppet ”överlämning” i kravarbetet!

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! Läs mer

Olika branscher – samma förutsättningar

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”.  Läs mer

Lean from the Trenches

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.

Läs mer

Krav som beslutsunderlag

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!  Läs mer

Mastering the Requirements Process – En kravresa

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. Läs mer

Att vara iterativ utan att vara agil

Det finns inget ord som både brukas och missbrukas så mycket i vår bransch just nu som ordet Agile. Alla ska vara agila. Vad det innebär exakt är inte så viktigt, bara vi blir agila. Det är det senaste, det bästa och det löser alla våra problem. Att många företag har svårt med en agil transformation är ett faktum och det kanske inte är så konstigt när man inte tar sig tiden att förstå vad en sådan faktiskt innebär. Man blir inte agil över en natt.

Läs mer

Var går gränsen mellan process och produkt?

Sketches

Jag börjar med att sticka ut hakan genom att generalisera rörande hur man är organiserad på större företag:

  • Den verkliga beställarsidan på företag är processorienterade, detta medför i det flesta fall att deras IT-stöd består av fler än ett verktyg.
  • Många gånger är IT-sidan på företag orienterade efter verktyg, åtminstone när det kommer till verklig implementering och exekvering.

Moderna utvecklingsmetoder förespråkar att man som beställare ska jobba nära implementationsteamet. Detta betyder, tillsammans med ovanstående generalisering, att en beställare kan ha fler än en motpart när det kommer till att realisera sina behov.

De senaste åren har jag jobbat både som kravställare och som kravhanterare. Jag har därmed erfarenhet av både egen och andras frustration kring när produkt/projekt krockar med process.

Läs mer

Gästinlägg: The user story considered harmful

Då drar vi igång Kravbloggen igen efter semestern och vi börjar med ett gästinlägg av inga mindre än Suzanne och James Robertson. Suzanne kommer till Stockholm och håller kurs den 27-29 september. Se mer här

The User story considered harmful

Agile techniques have brought us many advantages and good ideas – unfortunately, the user story is not one of them.

The user story is a “placeholder for a conversation”, or a “placeholder for requirements”, either definition is acceptable. However, if the story is a placeholder, then it must hold the right place, and must guide the conversation in the right direction. Many stories don’t.

What’s wrong with the user story?

The most fundamental problem facing software development today is that the single greatest cause of project failure is a failure of requirements. This “failure of requirements” covers the full gamut: failure to discover the needed functionality; failure to understand the nuances of the needed usability; failure to adequately convey the requirements to the developers; and frequently, failure to uncover the real problem to be solved. Sadly, the user story often directly contributes to the requirements problem.

So why are user stories poor in the requirements arena?

Läs mer

Dags att reflektera!

reflektera2

Ofta när man diskuterar kommunikation så handlar det om hur man ska förmedla något som ”avsändare” av information. Men eftersom kommunikation oftast handlar om en dialog så behöver vi erkänna att vi har två sändare och två mottagare. Det kan var en obalans av aktivitet mellan parterna men det är en dialog även om den ena pratar och den andra bara hummar jakande.

Det finns en term som jag tycker man kan använda sig av för att beskriva detta ”feedbackande” och det är att reflektera. Normal pratar man om att man reflekterar och summerar i samtal, men det är ett koncept som kan användas i mycket mer än samtal. Det belyser en otroligt viktig egenskap i kedjan att realisera ett krav. Det är inte en envägskommunikation som möjliggör att man träffar rätt – att behovet som kommunicerats initialt, faktiskt resulterar i just den ”feature” som faktiskt efterfrågades. Det kräver att man kontinuerligt återkopplar och säkerställer att det man hört faktiskt överensstämmer med det som var tanken hos avsändaren. Vi kan minimera risker genom att minska antalet led och överlämningar, men så länge inte idén föds och implementeras av samma person så behövs feedbackloopen (= reflektion). Det handlar ju inte bara om att bara putta information nedströms. Både avsändare och mottagare vill ha kvitto på förståelse, då information filtreras efter mottagarens hjärna och inte sändarens. Läs mer

Att involvera användaren

Låt mig presentera ett dilemma som jag då och då brottats med och även hört kollegor/vänner i branschen prata om. Ett dilemma som består av följande komponenter:

  • Ett projekt vars huvudsyfte är att ersätta befintlig lösning med en ny. Samma funktionalitet men baserat på ny, modern hårdvara och utvecklat i ett nytt och modernt programmeringsspråk.
  • En beställare och styrgrupp som med ett tydligt statement sagt att eftersom det är samma funktionalitet, så behöver vi inte kommunicera i onödan med slutanvändarna. Ingen idé att röra upp damm och skapa oro.

Någon som känner igen sig? Någon som anar i vilken riktning detta blogginlägg är på väg åt?

Läs mer