Lätt att leka, svårt på riktigt

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!?

Fortsätt läsa Lätt att leka, svårt på riktigt

Sagan om Mäster Skräddare och varför blir det fortfarande såhär?

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.

Fortsätt läsa Sagan om Mäster Skräddare och varför blir det fortfarande såhär?

Är dina resultat lika tråkiga som de låter som?

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?

Känslan som lätt uppstår under en långdragen och tråkig presentation.

Fortsätt läsa Är dina resultat lika tråkiga som de låter som?

Lyssna inte på vad användarna säger!

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?
Fortsätt läsa Lyssna inte på vad användarna säger!

Att skapa samsyn med hjälp av processer

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.

Fortsätt läsa Att skapa samsyn med hjälp av processer

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.

Fortsätt läsa Lean from the Trenches

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. Fortsätt läsa Mastering the Requirements Process – En kravresa

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.

Fortsätt läsa Att vara iterativ utan att vara agil

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.

Fortsätt läsa Var går gränsen mellan process och produkt?

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?

Fortsätt läsa Gästinlägg: The user story considered harmful