Archive for april, 2010

h1

Prototype Driven Development – En utopi?

torsdag, 29 april, 2010

Denna vecka har jag fått seriösa griller i huvudet. Företaget jag höll kurs för i tisdags arbetade hårt med prototyping för att undersöka vilka koncept som fungerade och inte fungerade. Tänk om hela produktbackloggen kunde ersättas med en levande prototyp?

Fram tills i tisdags betraktade jag prototyping endast som ett verktyg för teamet och produktägaren för att flytta en funktioner och features från ”Anarchy” or ”Complex” space ner mot ”Complicated” eller ”Simple” space.

Prototypen blir närmast ett verktyg för groomingen av produkt-backloggen. När produktägare och kund sett och klickat runt i prototypen kan EPIC User Stories brytas ner, detaljeras och prioriteras (eller förkastas). När detta arbete är gjort har prototypen spelat ut sin roll. Den fungerar alltså bara som ett ”hur”, ett verktyg att förstå vad man vill ha och vad som fungerar bäst, ett steg i utvecklingsprocessen på resan mot att leverera värdefull och användbar mjukvara.

Med lite tur kan man ibland återanvända lite kod från prototypen till den ”riktiga” produkten men oftast har den spelat ut sin roll och förkastas till skräpkorgen (eller arkivet).

.

Men nu snurrar (för mig) många nya tankar, åtminstone kring prototyping av gränssnitt och dialoger. POC:ar för att undanröja tekniska frågetecken eller risker lämnar jag därhän för tillfället.

.

För, tänk om…

  • Vi inte alls förkastar våra olika prototyper utan prototypen föds i tidig analysfas och fortsätter sedan leva, förändras och växa genom hela projektet.
    .
  • Prototypen är så enkel att bygga ut och laborera med att Produktägaren själv kan experimentera med att lägga till dialoger, skapa dummy-funktioner och koppla ihop systemet på olika sätt. (Kanske har produktägaren ett prototyp-team till sin hjälp eller så spenderar ordinarie team en viss tid av sin sprint för att skulptera prototypen som ett steg i det kontinuerliga analys- och designarbetet.)
    .
  • Prototypen kan ”spelas upp” i olika skepnader. Man bygger inte en helt ny prototyp för att gestalta en annan variant av dialogen utan prototypen kan ställa in i vilket version vi vill experimentera med denna testkörning. Skepnader och flödesvarianter kan enkelt konfigureras on the fly.
    .
  • Vissa delar av prototyp-produkten består av luddiga dialoger och grova funktioner medans andra är tydligare, mer detaljerade och närmare en implementerbar nivå.
    .
  • Prototypen låter sig delas upp i funktioner och komponenter som teamet kan estimera.
    .
  • Estimaten behöver inte lagras i en separat lista någon stans utan är en del av modellen och kopplas till ”prototyp-komponenter”.
    .
  • Komponenterna kan innehålla dolda attachments som inte syns vid körning. Exempelvis word dokument, sökvägar in i wikin, osv.
    .
  • Komponenterna kan innehålla annan meta-information som t.ex:
    • Prioritet
    • Att-Göra-lista med öppna frågor för produktägaren
    • Vilket team som eventuellt ska bygga funktionen
    • Vilken release/sprint funktionen eventuellt är planerad till
      .
  • Slutligen så går prototypens komponenter att skriva ut som en prioriterad lista. Denna lista kommer snarare likna ett träd med grenar som spretar iväg. Ibland lever flera varianter av samma funktion (User Story) fram tills dess att en av dem implementeras och andra förkastats.

Kommentar: När jag skriver ”komponent” ovan menar jag inte modul eller klass, jag syftar till en dialog eller en specifik funktion i användargränssnittet.

.
.

Om denna fantasi besannas har vi då helt och fullt lyckats ersätta produktbackloggen med en prototyp?

Men varför stanna där? Anta att plattformen och språket vi bygger prototypen med är samma som vi använder när vi bygger den ”riktiga” produkten och att implementera en komponent/funktion i prototypen enbart handlar om reda ut återstående detaljer, skriva koden bakom, testa av samt rensa bort döda versioner och aspekter?

Når vi hela vägen hit är vår release-branch helt enkelt en specifik konfigurering av prototypen. Känns definitivt som en utopi men kanske ett vision att arbeta mot?

h1

Nästa Scrum User Group Sweden är 19:e maj

måndag, 26 april, 2010

Häromdagen sattes datumet för nästa Scrum User Group Sweden. Den sjätte träffen i ordningen. Denna gång är teamat ”Scrum och andra gila metoder”, gissningsvis kommer det bli mycket diskussioner kring Kanban då detta är på modet inom den agila världen just.

Är du intresserad och vill anmäla dig så se till att göra det så snart du kan då antalet platser är begränsade till 40 stycken. Träffen sker precis som vanligt i Stockholm (vilket jag tycker är lite tråkigt men jag eftersom grundarna och drivkrafterna bakom gruppen finns i Stockholm så är detta kanske bara naturligt). Agendan ser ut som den brykar, först några blixttal följt av ett Open Space. Mycket lyckat och roligt upplägg tycker jag!

Du anmäler dig och hittar mer info på google groups.
Gruppen ”Scrum User Group Sweden” hittar du här:
http://groups.google.com/group/scrum-user-group-sweden.

h1

Super Sprint Demo – Alla team samtidigt!

fredag, 23 april, 2010

Tydligen jobbar aftonbladets IT avdelning enligt Scrum. Inte bara så har de en stor öppen demo för alla intresserade på företaget, de publicerar också en summering av demon på blogg.aftonblandet.se/dev för alla andra nyfikna långt utanför projektets väggar. Texten ger en kort men rolig insyn i deras arbete, specifikt deras nya upplägg kring sprint-demos.

Jag har varit med om att flera team schemalagt sina demos spridda över en och samma dag för att man ska kunna delta på alla som intresserar en.

Jag gillar dock detta grepp ännu bättre, dvs. Aftonbladets 6 Scrum team organiserar ihop sig för en gemensam demo varannan vecka (dvs. deras sprintar är två veckor långa). På detta sätt blir det en naturlig företags-happening som drar uppmärksamhet till sig och förhoppningsvis skapar engagemang och intresse. Gissningsvis växer också engagemanget och motiveringen att nå sprint-målen i varje team då demons publik är mycket större.

Dock undrar jag hur de gör med dialogen och feedbacken… Måste bli smått ineffektivt att samla in synpunkter, idéer och feedback från en så stor publik (som bilden skvallrar om) i slutet av demon. Jag misstänker kanske att blogg-inlägget missar att beskriva detta (eller så är det så att varje team bygger efter egen drivkraft och kanske inte är speciellt beroende av återkoppling från kund eller stakeholders).

Hur som, jag hoppas jag snart får möjlighet att beskåda något liknande med egna ögon och vara med och uppleva vad en dylik förändring innebär för motivation, fokus och kommunikation mellan IT, verksamhet och beställare.

Finns det andra därute som har erfarenhet av motsvarande upplägg, dvs. stor gemensam team-överskridande sprint demo?

.

Läs hela artikeln på Aftonbladets ”Utvecklingsbloggen”.
(Bilden är hämtad ifrån utvecklingsbloggens flickr
album)

h1

18 tomater på en dag och inte ens ett vettigt blogg-inlägg

torsdag, 22 april, 2010

Pust. Är inte säker på att jag använder tekniken som tänkt men å andra sidan växer ibland arbetet till ett mindre berg, och då helgar ändamålet medlen. Pomodoro tekniken har iallafall gett mig ett verktyg med vilket jag kan jobba riktigt fokuserat, systematiskt och effektivt med.

Nu återstår bara att summera dagens aktiviteter och lägga till ”Fråga Jelena och/eller Joakim om jag missbrukar/missförstått metoden” till min Activity Inventory. När jag började dagen imorse anade jag aldrig vad som låg och ruvade på mig i väntan på att jag skulle tillfriskna från min förkylning tidigare i veckan. (Av dagens tolv aktiviteter förutsåg jag fem imorse…)

Nu ska jag försöka varva ner och sedan sova så att jag är pigg och taggad inför morgondagen. Imorgon kommer jag och en ca 24 kollegor (trainees och nyanställda) sätta tänderna i den nyframtagna Scrum kursen ”Sogeti Scrum Course Compact”. Dels ska det självklart bli riktigt roligt, men det ger mig också en chans att prova innehållet och mitt upplägg inför kommande kurser som går av stapeln ute hos kunder de närmaste veckorna.

.

Riing. Nu kom jag upp i 19 pomodori…

h1

Te, XBox och lite läsning

tisdag, 20 april, 2010

Idag kommer det inte bli många knop gjorda. Förkylningen har slagit ned sina bopålar så det är bara att gilla läget.

Ambitionen för dagen blir kort och gott:

  • Dricka te
  • Ringa och kolla läget med teamet, hur de mår och höra efter om det brinner någonstans
  • Spela XBox 360 (Dragon Age: Origins)
  • Läsa några kapitel i ”Pomodoro Technique Illustrated” samt bläddra igenom boken ”Agile Product Managment Using Scrum – Creating Products that Customers Love” som anlände igår (Kanske t.o.m. blir en recension på någon av dem under veckan)
  • Stretch-goal: Förbereda inför fredags kurs (utifall jag skulle frisknat till till dess)
h1

Råd till den girige produktägaren

måndag, 19 april, 2010

Dras dit team med en person som fått rollen som produktägare och som envisas med att sätta ”Måste”-prioritering på allt? Eller hör du kanske själv till skaran beställare som blir frustrerad när teamet ber dig prioritera ”User Stories” och som inte förstår dig när du försöker förklara för dem att ”alla dom här funktionerna är oerhört viktiga”?

Det är bra att du i rollen som Product Owner har en klar och tydligt bild av vad systemet minimalt måste bestå av för att det ska vara driftbart eller säljbart. Det är en viktig funktion. Men det är ännu viktigare att löpande omvärdera och ompröva omfattning och release planeringen för att kontinuerligt säkerställa att teamet just nu, i den aktuella sprinten, jobbar på det som ger dig mest värde för pengarna. Och att teamet gör det varje sprint.

Och stämmer det verkligen att systemet måste innehålla precis allt för att över huvud taget vara användbart? Troligtvis inte.

Så, här följer nu…

.

8 Råd till den Girige Produktägaren:

Jag har prioriterat råden efter den ordning jag tycker man ska följa dem  😉 Vidare, när jag skriver ”Story” i texten nedan syftar jag till User Story/Feature/Funktion.

  1. Visa förtroende för teamet
  2. Välj leveransordning
  3. ”Beställ” det som är av mest värde först
  4. Inspirera teamet
  5. Överbelasta inte teamet
  6. Ge teamet bra förutsättningar
  7. Finns till hands
  8. Ha tålamod

.

1. Visa förtroende för teamet

Lita på att teamet gör sitt yttersta för att lyckas – varje sprint. Visa att du har förtroende för att de har den kompetens som behövs och visa tillit till att de sköter sitt jobb.

Försäkra dig om att teamets Scrum Master gör ett bra jobb vad gäller att skydda teamet från yttre störmoment så att teamet ostört kan fokusera på att leverera de funktioner de lovat.

(Blir du motbevisad och det visar sig någon i teamet grovt missköter sitt jobb är detta något som såklart behöver adresseras, kanske t.o.m. i projektets styrgrupp.)

.

2. Prioritera efter leveransordning

Teamet hinner bara bygga och leverera ett begränsat antal färdiga funktioner/features per sprint. Att designa, utveckla och testa av funktioner och features tar tid.  Hur mycket du som produktägaren än vill så kan inte teamet leverera hela produktbackloggen på en sprint. Att sätta Måste-prio på allt hjälper vare sig teamet eller dig. Det skapar snarare enbart frustration.

Om du istället betraktar prioriteringen som leveransordning (i motsats till hur viktig eller oviktig Storyn är) så borde uppgiften bli enklare. Vilken funktionen vill du helst se ska visas upp på nästa sprint demo?  Låt sedan teamet plocka så många de förmår ifrån ”leverans-kön” när de planerar sin nästa sprint.

Ser du till att göra ”leveransobjektet” (dvs. User Storyn) lagom liten och tydligt avgränsad, och dessutom enbart innehåller det du är säker på att du vill ha, då minimeras risken att teamet bygger något som senare behöver göras om eller förkastas.

.

3. ”Beställ” det som är av mest värde först

Prioritera först och främst efter affärsvärde och verksamhetsnytta. Vilken funktion uppfyller affärsmålen bäst? Vilken features skulle glädja flest användare mest?

Ibland kan dock andra faktorer spela in din prioritering:

  • Risk – Bakom en viss funktion kanske höga tekniska risker och svårigheter döljer sig. Då kan det vara en god idé att undanröja eller bekräfta dessa risker tidigt.
  • Osäkerhet – Misstänker du att du som Product Owner kommer ha mycket åsikter och feedback kring något, se till att den Storyn levereras tidigt så att det finns tid innan release att prioritera med eventuella ändringsförslag och justeringar.
  • Beroenden – Det kan vara så att teamet upplyser dig om tekniska beroenden Storys emellan, dvs. det är kanske omöjligt att först (eller åtminstone mycket dyrare)att utveckla X om inte Y är utvecklat först.

.

4. Inspirera teamet

För att teamet ska bygga så ”rätt” som möjligt är det såklart bra om de förstår varför du vill att en funktion ska bete sig på ett speciellt sätt eller varför just den featuren är viktig för användare. Bjud in teamet att vara delaktig i den större visionen.

Om teamet förstår nyttan, och känner att det de utvecklar faktiskt kommer att glädja användarna, stiger såklart motivationen och engagemanget.

.

5.   Överbelasta inte teamet

Stressa inte teamet till att lova för mycket under en sprint. Låt inte teamet heller lura sig själva till överoptimistiska löften. Om teamet till exempel helt plötsligt och omotiverat ändrar sina estimat till mer optimistiska värden under sprint planeringen bör du vara vaksam.

Det sista du vill är att teamet tvingas (eller själva väljer) att ta genvägar och fuska med design, test och kvalitet för att hinna leverera allt det de åtagit sig. Halvfärdiga, slafsiga och otestade funktioner innebär bara framtida kostnader i form av dyrare underhåll och högre teknisk skuld. Ju högre teknisk skuld, desto mindre kommer teamet klara av per sprint framöver.

Väldigt kontraproduktivt med andra ord.

.

6. Ge teamet bra förutsättningar

För att teamet ska kunna ge så bra sprint mål som möjligt och för att teamet ska kunna vara så effektiva som möjligt under sprinten behöver de såklart bra förutsättningar för detta.

  • Innan sprint planeringen, se till att produktbackloggen är uppdaterad och prioriterad.
  • Försäkra dig om att dina högst prioriterade storys är detaljerade (dvs. tillräckligt detaljerade för att teamet träffsäkert ska kunna estimera och bryta ner i sub-tasks)
  • Bjud in teamet till Story Time Session några dagar innan sprint planeringen. Här presenteras och diskuteras nyheter i produktbackloggen, teamet ställer frågor och uppdaterar eventuellt estimeringar. (Behövs finns nu tid innan sprint planeringen för dig att kolla upp detaljer och för teamet att undersöka tekniska frågetecken.)

.

7. Finns till hands

Se till att du är tillgänglig för teamet så att de snabbt kan få tag i dig för att ställa frågor om detaljer eller behöver din feedback. Jag gissar att du inte vill att teamet sitter och rullarna tummarna istället för att bygga funktioner åt dig…

Försök närvara på teamets dagliga möten för att fånga upp eventuell bekymmer som du kan hjälpa till med. Se dock till att inte störa teamet! Antingen håller dig tyst i bakgrunden under Daily Scrum och ställ dina frågor till Scrum Mastern efteråt, eller så ställer du dig i ledet som vilken teammedlem som helst och svarar på de tre frågorna när det är din tur.

När teamet väl har demonstrerat så utöva din makt att utvärdera, prioritera om och kanske till och med ändra release planen för projektet.

.

8. Ha tålamod (en liten stund)

Självklart ska du ställa höga krav och förvänta dig att teamet presterar sitt bästa, men när teamet väl har börjat sin sprint och ni har skakat hand på sprintens mål, ge dem arbetsro och möjlighet att fokusera på sitt arbete. Riv inte upp deras planer genom att förändra sprintens målsättningar eller introducera helt nya krav. Var delaktig i arbetet men sabotera inte teamets möjligheter att lyckas.

Om du ofta finner dig i en situation där du avbryter teamet och ber dem jobba på något annat som blivit viktigare (och som inte kan vänta till nästa sprint) kanske det är dags att diskutera kortare sprintar? Eller också kanske Scrum Master ska läxas upp eftersom han uppenbart misslyckas skydda teamet från yttre störmoment 😉

.

Varför följa ovanstående råd?

För varje råd du följer ovan desto bättre förutsättningar och möjligheter får teamet att lyckas med sin leverans under pågående sprint. Det de bygger blir rätt, behöver inte göras om och håller hög kvalitet. Du ger dem också möjlighet att hålla samma (och förutsägbara) tempo, effektivitet och kvalitet varje sprint.

Det är väl precis det du vill? Få ut så mycket av värde som möjligt från teamet.

Varje sprint.

h1

Chuck Norris har svart bälte i Agil utveckling

fredag, 16 april, 2010

En natt i februari pågick det ett livlig twittrande om den fantastiske Chuck Norris, eller åtminstone om hur fantastisk han hade varit om han hade jobbat agilt.

Här är en summering över de nya Chuck Norris skämten som uppstod natten den 19:e februari 2009 (översatta från tyska av okänd). Har jag missuppfattat ursprunget av denna listan skriv gärna en kommentar.

.

  • Chuck Norris is ScrumMaster and ProductOwner – simultaneously.
  • Chuck Norris can do 6-month sprints.
  • Chuck Norris wears Timeboxershorts.
  • Chuck Norris does not move story cards, he moves the taskboard.
  • Chuck Norris does not estimate, he knows.
  • Chuck Norris pairs alone.
  • Chuck Norris is allowed to appear late at the stand-up.
  • Chuck Norris sits on the stand-up meeting.
  • Chuck Norris has implemented everything at the planning meeting.
  • Chuck Norris writes the code first, then the test.
  • Chuck Norris is not afraid of bugs, bugs are afraid of him.
  • Chuck Norris does not do Kanban. He does not know limits.
  • Chuck Norris does not pull, he pushes.
  • When Chuck Norris says “done”, then it’s “done”.
  • Chuck Norris does not deploy, he develops on the production environment.
  • Just Chuck Norris knows, that a real burn-down requires napalm.
  • Chuck Norris has no burn-down chart. Around him everything is already burnt down.
  • Chuck Norris answers just two questions on the stand-up meeting. Chuck Norris does not know obstacles.
  • Chuck Norris does not prioritize the backlog, he is the backlog
    .
    och slutligen…
    .
  • Chuck Norris always wins at Planning Poker.

.

Fick list-tipset av min flickvän (som i sin tur fick det av en kollega). Tack älskling! 🙂

.

För en mer längre och mer komplett lista se klicka här.

h1

Projektledningsaspekter i Scrum?

torsdag, 15 april, 2010

När jag är ute och föreläser om Scrum för en publik som är nyfiken på agila utvecklingsmetoder så är det oftast projektledare och arkitekter som skruvar på sig mest och ställer flest frågor.

Speciellt projektledare verkar ha svårt att se hur sin egen yrkesroll passar in i Scrum. Uppgifter och ansvar som typiskt åligger en ”klassisk” projektledare förekommer naturligtvis i Scrum också, fast i annan skepnad och ansvaret distribueras mellan flera olika personer. Jag ska därför försöka mig på att presentera en översikt över hur de olika ansvarsområden som en projektledare har i ett vattenfallsprojekt hanteras i ett Scrum projekt.

.

Projektledningsaspekter i Scrum

(eller ”Vem ansvarar för vad?”)

.

Varför? Hur ser visionen ut?
Varför bygger vi detta system?
Product Owner
(och kund)
Vad? Vilka features är användbara och värdefulla för kund och användare?
När? Vilka features har mest värde för kund och användare? (Dvs. i vilken ordning ska vi bygga och leverera för att maximera Return of Investment och minimera Time To Market?)
. . .
Kostnad? Hur jobbigt är det att bygga en viss funktion?
Hur lång tid tar det?

Vilka kunskaper behövs?

Scrum Team


Hur? Hur ska funktionen byggas (från ett tekniskt perspektiv)?

Vilken arkitektur och design är bäst?

. . A
Hur? Efter vilka spelregler (process) jobbar vi?

Hur förbättrar vi processen och våra metoder?

Vem ansvarar för att teamet får förutsättningar och möjlighet att utföra ett bra jobb?

Scrum Master


. . .
Problem? Lyfta frågor rörande…

  • Resurser och behov
  • Förändringar i Release planer (omfattning eller tid)
  • Tekniska beroenden mot andra team

…till Meta-Scrum (Styrgrupp) eller till Scrum-of-Scrums?

Alla

h1

Agila verktyg i min Android

onsdag, 14 april, 2010

Har upptäckt att det finns en hel del små fiffiga appar på min Android som kan vara bra att ha till hands för utvecklarna i det agila teamet och den gadget-glade Scrum Mastern. (Jag är säker på att samma appar eller motsvarande går att hitta till iPhone också.)

När jag började skriva detta inlägg tänkte jag ta upp alla appar jag hittat hittills men då hade inlägget återigen blivit på tok för långt så därför fokuserar jag denna gång på några time-managment appar.

.

Pomodoro timers

Har precis börjat studera Pomodoro och praktiserar det faktiskt just nu! Därför blev jag glad när jag upptäckte en radda appar för ändamålet. Pomodoro går kort och gott ut på att man gör en To Do lista för dagen, angriper den punkt man tycker är viktigast, vrider upp timern på 25 minuter, jobbar oavbrutet och fokuserat på vald uppgift tills klockan ringer, tar en kort paus och väljer sedan den punkt i To Do listan som känns viktigast nu (eller så väljer man att fortsätta på uppgiften man höll på med om man inte blev klar). Jag föredrar dock alltid en riktig timer framför dessa appar men det är inte alltid man har en till hands och det är inte alltid folk runtomkring en uppskattar tickandet och ringandet.

Pomodroid
(Utvecklad av: Neto Marin)

En simpel timer man kan start och stoppa. Startar alltid om på 25 minuter (ej konfigurerbart). När man klickar på skärmen startar timern och tomaten blir röd. När 25 minuter har gått ringer och vibrerar telefonen. Kort och gott. Gillar appen för dess renhet och enkelhet.

.

Pomodoro Tasks
(Utvecklad av: Kavan Puranik)

Denna Pomodoro app är lite mer avancerad. Du sätter upp din To Do lista innan du startar timern för en vald uppgift. Listan kan sorteras om, tasks stryks enkelt med en fingerdragning och lite andra funktioner finns.

Även om det är en fin idé så faller appen också lite på just dess utbud av funktioner, det finns helt enkelt inte stöd för allt man vill göra (som t.ex. anteckna hur många pomodoros en uppgift tog m.m.). Känner själv att verktyget begränsar mer än hjälper.

.

Meeting Time Tracker
(Utvecklad av: Espinassous Etienne)

Ett enkelt verktyg i första hand designat för Scrum Mastern eller mötesordföranden för att se till att möten inte överskrider Time-boxningen.

Du stället helt enkelt in hur långt mötet är och startar timern. Utöver att skriva ut tiden visar den även hur status på hur långt det är kvar; hälften, 15 minuter, 10 minuter och 5 minuter. (Planerar att använda själv den på fredag när det är dags för nästa seminarie för att enkelt hålla koll på om jag hinner med dom slides jag tänkt mig innan nästa paus.)

h1

I gränslandet mellan Scrum och Vattenfall

tisdag, 13 april, 2010

Nu så har dedikerad testare vaknat till och engagerat sig i ett av projektet jag är engagerade i just nu. Arbetsmetoder börjar ta form, ansvarsgränser målas upp men det tighta schemat genomsyrar hela tiden diskussioner, taktik-snack och projektgruppsmöten.

Test Planen ska diskuteras nästa vecka men jag gissar att jag kommer ha mycket åsikter och synpunkter då den tagits fram med en stor kappsäck av vattenfallsmentalitet trots att projektets testcoach vet om att vi angriper utvecklingsfasen i projektet med Scrum. Min egen roll i projektet är Technical Lead och Scrum Master.

En annan utmaning jag tampas med på daglig basis är kommunikationen med projektledaren. Hon gör ett fantastiskt jobb att koordinera alla parter (stort integrationsprojekt) men hennes angreppssätt är att strikt rada upp allting sekvensiellt och mäta progress i %, oavsett vad det rör sig om. Allt eller inget.  Antingen är det inte påbörjat, X% klart eller helt klart. Inget utrymme för förändring i målbild eller utförande. Dvs. vattenfall. Tilläggas kan att programmeringen och test tar upp ca 10 rader i hennes 120 rader långa detaljplanering. ”Do not touch my perfect plan” får vara dagens citat. (Levererades när jag försökte påpeka att planen kanske borde uppdateras med hänsyn till vår nya kunskap).

Det kommer att bli några spännande sprintar framöver för utvecklingsteamet och mig själv när vi ska försöka leva, leverera och överleva i gränslandet mellan Scrum och Vattenfall. Den uppenbara risken är såklart att eventuella förseningar och/eller problem skylls på den nya kompisen i gänget (Scrum) istället för de sanna grundorskarna (som t.ex. skulle kunna vara dåliga estimat, dåliga förustättningar eller yttre störningsmoment för att nämna några) och att den nyväckta glöden till Scrum i utvecklingsteamet släcks.

Men det är också såklart väldigt utmande och spännande att få vara med att påverka en organisation till att jobba mera agilt och att lära sig fokusera mer på det levererade affärsvärdet, eliminera arbete som är tidsslöseri samt  maximera kontaktytan mellan utveckling och beställare för att bygga så bra lösningar som möjligt. Speciellt roligt är det såklart när stakeholders och teammedlemmar själva kommer med förslag som gör processen och arbetssättet mera agil.

Skulle det börja regna för mycket i vattenfalls-land är det bara göra som man brukar, ta på sig regnjackan och kavla upp ärmarna och jobba på så gott man kan tills man kommer i mål.

För eller senare så tror jag att alla företag som är intresserade av att överleva i en hårt konkurransutsatt marknad måste övergå till en lean organisation som utvecklar agilt.

Jag kommer med stor säkerhet få anledning att återkomma med fler reflektioner, kommentarer och summeringar hur det går för oss att leverera mjukvaran enligt Scrum till ett projekt som i övrigt drivs enligt vattenfall.

Fram tills dess tänker jag falla tillbaka på mantrat:
”Fake it until you make it”!