Mikael Deurell : Scrum

How Microsoft does Scrum and CI

mikaeld — Sat, 08 Mar 2008 12:14:00 GMT

En inte helt ovanlig fråga jag får när jag är pratar om Scrum, Crystal Clear, CI, VSTS, TFS och annat ASD relaterat med våra kunder och partners är:

- "Men Micke, hur gör ni själva?"

Microsoft har under de senaste åren blivit en härlig Scrumfabrik. Över 30% av alla projekt som körs internt på Microsoft använder Scrum som bas och när vi pratar ASD är Scrum och Continuos Integration de delar vi driver hårdast. Det härliga med att vi använder våra egna produkter (TFS) internt är att våra features i VSTS/TFS riktas mot de områden vi tycker är viktigast, och kopplat till detta ge teamen/våra kunder ett verktygsstöd som rockar! Men vad använder vi mest? Microsoft Research har gjort en intern undersökning kopplat till användandet av ASD (Agile Sofware Development) och ni kan ladda ner den här. Lite härlig helgläsning!!! :-)

Scrum i praktiken med Björn Eriksen

mikaeld — Sat, 22 Sep 2007 09:42:00 GMT

Björn har tagit fram en cool tvådagarskurs i Scrum/XP som är utformad på ett sätt som gör mig både avundsjuk och stolt! Jag får inte sällan frågor om att köra utbildning med just denna inriktning. Första dagen en ordentlig genomkörare av Scrum och andra dagen komplettera med engineering practices från XP och haka på verktygsstöd med BÅDE VSTS/TFS OCH ALT.net.

Björn kommer att jobba som MCT/ATE instruktör på TechEd i Barcelona, hugg tag i honom, bjud honom på tapas/öl och muta till er kursmaterialet... Eller gå kursen!!!

Bra jobbat Björn!!! You rock!

Ska vi förlänga en sprint om vi håller på att misslyckas?

mikaeld — Thu, 16 Aug 2007 08:59:00 GMT

Vi har en hel del agila forum på Microsoft. Väldigt ofta snöar vi (som agila forum alltid verkar göra) in på någon intrikat detalj eller tolkningsfråga som i de flesta fall är totalt meningslös, men ändå charmig att stöta och blöta några vändor. För någon vecka sedan kom dock en schysst praktisk fråga från Eve Rallo på Connected Systems Division. Vad gör vi om vi bara är en liten liten liten pyttebit från att vara klara men inte kommer att fixa kakan inom aktuell sprint? Det är ju bara så jääääättelite kvar... Snälla... Får jag förlänga... Snääälla...

Alla som kört agila projekt känner nog igen sig... Och kanske även hör Ken Schwabers röst i bakhuvudet... Men... Varför skall man inte förlänga sprinten? Om det bara är pyttelite? Pytte pytte pyttelite...

En härlig praktiskt orienterad diskussion som vi la upp här... Kolla!

Det underbara i kråksången. Microsoft har massor av sköna praktiskt orienterade, PASSIONERADE agila team som driver detta med glöd i ögonen... Har jag sagt att jag gillar att jobba här... ;-)

The Human Element

mikaeld — Sat, 02 Jun 2007 09:45:00 GMT

Efter att ha jobbat en hel del med teamcoachning och msf agile har jag lärt mig var man skall lägga tyngden, och vilka delar man högaktningsfullt kan %¤#%" i. Vill man ha resultat snabbt, gör följande:

1. Inför daily builds
2. Satsa ALLT på att trycka teamet genom FIRO

Allt handlar om teamet, allt det som det jiddras så mycket om, möblering av projektrum, teamestimering, empowerment och hela kakan är old school! Inget nytt! Will Schutz fångade detta i FIRO teorin redan 1958. En teori som använts länge för att utveckla högpresterande team (t.ex. specialförband i militären). Jag sprang på denna för första gången 1992 när jag tjänstgjorde som fallskärmsjägare i armén. Andra gången var när jag jobbade som teamledare på Connecta. Allt var redan dokumenterat och beprövat, långt innan dess att vattenkammade tekniker fick agile-feber.

Vi frågar alltid varför IT-projekt är så svåra. Mitt svar är ganska enkelt (så enkelt att Dag anser att jag hela tiden kommer med "jag har klämt två pilsner och kommit på detta" lösningar), de är oftast inte det. Det är klart att det finns svåra IT-projekt men de flesta som misslyckas är egentligen ganska enkla... En dataentry app för att registrera försäkringar, kan det vara svårt? Varför drog det projektet över tiden med ett år? En app för att optimera pumpkonfigureringar? Kom igen... Det är inte så #%¤%"# svårt... Nagelbitande akademiker gräver ner sig och jämför systemutvecklingens komplexitet med människans biologiska uppbyggnad. I min värld är det en schysst skillnad på hur hjärnan är uppbyggd och hur man skyfflar in Nalle Puh strumpor till ett ordersystem för en klädtillverkare.

Det är mycket sällsynt att hitta ett IT-projektteam som lämnat tillhörafasen, de har inte ens fått förutsättningarna. Att jämföra IT-projekt med människans mysterier är absurt, men en jämförelse är intressant.

Om du skulle in för operation på ett sjukhus, skulle du hellre bli opererad av ett läkarteam som uppför sig som ett kirurgteam eller ett läkarteam som organiserat sig som ett klassikt IT-projekt? Jag vet vad jag skulle välja...

And history books forgot about us
And the bible didn't mention us, not even once
You are my sweetest downfall
I loved you first...

Microsoft sommarkollo

mikaeld — Wed, 18 Apr 2007 17:39:00 GMT

Skickade just in min session till sommarens "Microsoft - Sommarkollo". Vad tror ni? Kommer ni? :-)

Sommarkollo – MSF och agila metoder
Hur kan vi få projektledare till att driva projekt framåt, istället för att fokusera på nerlagd tid i procent? Vad gör egentligen en arkitekt? Hur kan vi gå från en modell där vi försöker testa in kvalitet till att faktiskt bygga in den från början? Och viktigast av allt; hur bygger vi team som rockar och som kan anpassa sig till en föränderlig verklighet? MSF agile erbjuder ett ramverk och en process som svarar på dessa frågor baserat på våra erfarenheter inom Microsoft. Vi går igenom grunderna i MSF agile, tar upp exempel från verkligheten och kombinerar förhoppningsvis detta med en portion humor.
Målgrupp: utvecklare, projektledare, arkitekter
Föreläsare är Mikael Deurell, Microsoft
Level: 200

Agile Development Center på MSDN

mikaeld — Sun, 15 Apr 2007 20:48:00 GMT

Vi fått upp ett Agile Development Center på MSDN! Microsoft har av någon anledning varit ett lite för väl dolt Scrum-näste... Vi har så mycket bra beprövade erfarenheter från både DevDiv (Developer Division) och MCS (Microsoft Consulting Services). Nu är det dags för oss att få ut dem! Det luktar vår!!! :-)

Jag önskar att jag varit smart nog att ha skrivit detta själv!!! Wow!

mikaeld — Tue, 27 Feb 2007 10:42:20 GMT

Efter att ha coachat och genomfört tämligen många workshops kring MSF:agile har jag lärt mig följande;

1. Våra böcker om MSF är fruktansvärda!
2. En förståelse av Scrum gör ingången till MSF:agile mycket lättare
3. Det behövs två ingångar för att kunna tackla ett införande av MSF:agile. War Stories och en genomkörare av frameworket/processen.
(Konstpaus…)
4. Certifieringar som bygger på att man degar upp pengar utan att behöva prestera något suger! (oavsett om det är scrum-master eller arkitekturorienterat)

Jag har under en tid skrivit på en bok kopplat till punkt 3. Döm av min förvåning när jag hittar två UNDERBARA dokument som beskriver EXAKT det jag ville skriva om (iofs Scrumrelaterade, men ni som känner mig och vet vad jag tycker…) och de är gratis!

En snabb genomkörare av Scrum, skrivet av de vänliga människorna på Softhouse hittar ni här. Bra rekommenderad läsning för deltagarna innan ni kör en workshop om Scrum/MSF:agile.

Henrik Kniberg från Crisp har skrivit ett helt makalöst, underbart, war story-orienterat (Vi testade detta och det funkade/funkade inte hos oss) dokument (90 sidor) med klockren beskrivning av praktiska erfarenheter direkt från projektrummet. Så bra att det kom tårar första gången jag läste det!!!

Båda dokumenten är skrivna av svenskar och det är så långt ifrån fingercymbaler och taffliga processfundamentalister man kan komma. Tack! Uppfriskande! Ladda ner!!!

Too many fingers, too many thumbs
Something wicked this way comes
The best time I've ever had…

Ok, jag är KLAR! Vad #%&#¤% betyder det?

mikaeld — Wed, 14 Feb 2007 21:07:00 GMT

En av de absolut viktigaste sakerna att vara TYDLIG med i MSF-Agile projekt är när man är klar, klar på olika nivåer;

Klar på:
- Product Backlog nivå
- Iteration (Sprint) nivå
- Scenario nivå
- Klar för integration (att reverse integrera (RI) teamets privata branch till main trunken)
- Klar för deployment till produktion

Ok, nu vet jag att många säger, vi skall alltid vara klara för produktion, bra mindset! Men... Har ni fått detta att fungera i större skala någon gång? När fler feature-teams har privata branchar som kör RI mot trunken och en release skall ut (kanske en vacker beta) som innehåller features från båda feature teamen... Sannolikheten att ni får en ny bild av aktuell prestanda när ni kör prestandaanalys över hela releasen (betan), tillskillnad från de perf tester ni köre på de båda featureseten i teamen är iallfall relativt hög (100% :-)).

Så ett förslag är att innan ni kickar igång den första iterationen är klara (:-)) med vad som menas när ni säger att ni är klara... Ännu ett ämne att ta upp på en kickoff,istället för att spela någon lam discobowling och dricka fulöl... Här kommer ett förslag på en template...

Gör en egen mall och släng upp den på en vägg i projektrummet så att alla i projektet hela tiden vet vad Klar betyder! Bra för moralen, teamandan och tar bort gnabb! Lysande!!!

If it can be broke then it can be fixed, if it can be fused then it can be split
It's all under control
If it can be lost then it can be won, if it can be touched then it can be turned
All you need is time...

MSF agile! Rockade flygplan? Eller fingercymbaler och kärlekschakran?

mikaeld — Sun, 11 Feb 2007 21:05:00 GMT

En sak som slår mig efter att ha varit ute och hjälpt till i projekt som kör Scrum/XP/MSF agile är att resan ser liknande ut på de flesta ställen. De som misslyckats hårt har valt att lita på någon fingercymbalspelande "Agile-guru" som sagt att "Ni måste köra hela paketet för att vara agila, annars är ni bara kamouflerat vattenfall..." eller någon liknande mindre begåvad kommentar. De som fått mest värde på kortast tid har gjort följande;

1. Infört daily builds
2. Implementerat agile motorn (Som är extakt likadan i Scrum/MSF agile och XP)
3. Lyssnat på hur projektgruppen reagerat på detta och anpassat införandeprocessen efter detta...

Och när jag tänker på det så känns det självklart... Först får vi igång hjärtslaget i projektet, sen börjar vi springa och beroende på hur tränade vi är så anpassar vi farten. Cool...

Vad menar jag med motorn... Jag tar detta ur ett MSF agile perspektiv men detsamma gäller för Scrum/XP (Hey, ta Scrum, lägg till engineering practices från XP och komplettera med MSF core (teammodell och workstreams) så har ni MSF agile)

Inför varje iteration tar vi vår prioriterade scenario/QoS backlog (Product backlog) och stämmer av med kunden om hur många scenarios vi kan köra under denna iteration. Efter detta kör vi en härlig session planning poker med teamet för att tidsestimera varje scenario/Qos. För att koppla till flygplansanalogin jag körde tidigare så har vi precis tankat upp AN2an (ett vackert gammalt ryskt flyplan ;-)), men vi har inte startat motorn och börjat flyga...

Det som ofta blir lite trixigt i början i Scrumprojekt är rollfördelning och hur teamet skall jobba, en inte helt ovanlig tolking av detta i Scrum är att "projektet skall på ett magiskt hippieliknande sätt själv svänga in sig och alla skall hitta de roller som de är födda att ha... Och sen skall alla få blommor och fingercymbaler...". Utan en bra coach så sätter man inte detta utan en "lååång" resa. Jag brukar sno processen från MSF agile (för den är beprövad och bygger på hur vi på Microsoft skapar team som rockar). Hur gör vi då för att få upp flygplanet i luften?

Vi börjar läsa från "klocka 9". (När det gäller roller så är det ansvarsfördelning och inte att de ensamma skall utföra aktiviteten)

- En business analyst brainstormar scenarios/QoS med kund, prioriterar dessa
- En project manager schedulerar dessa för aktuell iteration
- Business analyst kompletterar scenariot (innan var det bara en mycket kort beskrivning)
- A/D/T bryter ner scenario/QoS till workitems och kör planning poker (om det behövs) för estimering. En person är alltid ansvarig för hela scenariot.
- Dev implementerar workitems
- När hela scenariot/Qos är färdigt kickar vi scenariot till nästa state (Resolved) och slänger iväg det till test
- Testare testar scenario/QoS och är allt ok så går det till Closed och vi kan börja köra nästa varv...

Det här är motorn... Tanka först, starta och börja flyg. I början är ni en AN2a men efter efter tid kommer ni bli en Twin-Otter... Vackert! Och skit i alla fingercymbalkommentarer från agile-gurus, lyssna till bra coacher som gjort resan förr och till er själva!!! Och anpassa er vartefter ni lär er mer...

Då många av de agileforum jag kollar på och är med i har en tendens att dra iväg nästan till religiösa former mellan varven (vilket är otroligt charmigt, men ibland lite väl weird) är det viktigt att hålla kvar verkligheten i det hela.

Ett litet förtydligande är på sin plats... Jag är absolut inte emot fingercymbaler, jag är ju gammal fallskärmshoppare där batikkläder, gemensam nakenbastu, digeridoospelande kring lägereld och att bli krokig till fader Zipsers gamla rullar tillhör vardagen... Men det finns gränser... ;-)

Cheers!

I'm the smallest lake
Fits in every city
Afraid the sun will dry me out
And I see lovers loving
And all the animals
Are drinking from my hand
Helps the sun to kill me...

Fresh from the vegetarian slow cooker : Tackle!

mikaeld — Tue, 30 Jan 2007 22:01:00 GMT

Idag släpper Tackle teamet ett helt underbart web-baserat Scrum tracking tool. Tackle används internt på Microsoft av många dev-team som kör Scrum och nu kan ni göra detsamma! Inte nog med det, vi ger er även all källkod så att ni kan kolla precis hur vi har gjort!!! Teamet som snickrade Tackle går under Microsoft Game Studios - Tools & Technology Team som bland annat snickrar tools till våra coola game devs...

Vad stöder då Tackle?

· Multipla Scrum Teams under samma site
· Multipla Product Backlogs per team
· Windows Authentication för att säkra backlogs
· Multipla sätt att prioritera backlogs
· Auto-generering av sprint backlog baserad på product backlog prioritering
· Report-mania; Sprint totals, sprint tasks per product/owner, burn down graph, status reports, work per day report, cross-scrum team reports, sprint review
· Tracka retrospective notes för varje sprint
· Online help och tutorial
· Och en massa, massa mer!

Tackle körs på SQL Server 2005 och asp.net 2.0 och använder självklart ATLAS som vi RTMade i förra veckan (Är själv livrädd för allt som går utanför UpdatePanel). Det här är så bra att man vill köpa shadade brickor, den coolaste ipoden och börja jobba för ett dev-team!

Ni hittar källkod, installers och info här!

Och glöm inte bort MSF:Core, även om ni kör Scrum...

A summer storm graces all of me
Highway warm sing silent poetry
I could bring you the light
And take you home into the night

MSF på hyffsat ren svenska, del 1

mikaeld — Sat, 16 Dec 2006 20:40:00 GMT

Då jag är en mycket varm anhängare till Microsoft Solutions Framework och jag kommit på att en av de största hindren för projekt att komma igång med hela MSF-tänket är att de flesta white-papers och böcker är tämligen tråkiga. En annan faktor är att man valt ut de absolut krångligaste orden på engelska för att beskriva helt lysande koncept som egentligen är långt ifrån komplicerade, kommer här unge herr Deurells "MSF på hyffsat ren svenska". Tänkte skriva en serie blogg entries med en intro till MSF då mycket av min tid på jobbet handlar om workshops och praktiskt jobb som nästan alltid knyts ihop med MSF...

Det häftiga med Visual Studio Team System och Team Foundation Server är att detta skapat ett härligt sätt att knyta in metod och process med ett mer pragmatiskt förhållningssätt till det aktuella projektet (till skillnad från att börja köra RUP genom att slänga in några feta metodböcker till projektrummet och sedan snabbt som #¤"%#¤ stänga dörren...). Det magiska med VSTS är att det blivit ett sätt att föra in metod/processstöd som ett naturligt sätt för att förbättra teamarbetet och leveransen. Att detta jobb sedan drivs från utvecklingsprojekten och inte som ett krav om metod-/processtillämpning som trycks ner i halsen på dev-projekt från någon avdelning som inte behöver ta ansvar för projektets resultat (Oftast ett ypperligt säkert sätt att misslyckas) är klockrent...

Låt oss se på VSTS som om det vore ett vackert, coolt jetplan som en dag landade i projektrummet. En naturlig fråga som skulle komma på morgonmötet (kanske en scrumsession) skulle förmodligen vara: "Hur "#¤%# får vi den där coola grejjen att börja flyga?". MSF är svaret på detta!!! Enkelt...

MSF består av flera delar, den absolut vackraste (och den som oftast inte får tillräckligt med uppmärksamhet) är MSF:Core. MSF:Core är ingen metod eller process utan mer ett beskrivande (descriptive) ramverk för vad som händer i en SDLC (Software Development Life Cycle) och tips på best-practices baserat på Microsoft (och andras) erfarenher. Här beskrivs några grundläggande koncept som är generella för alla SDLC, Foundational Priciples (för projektet i helhet och för individen), Team Model (hur bygger man ett fungerande team), Process Model, och disciplines (återkommer till dessa i en dedikerad blog-entry). Detta är med jetplans analogin färskt i minnet en generell beskrivning av hur flygplan flyger (det finns en landningsbana (tänk på att skotta den på vintern), kontrolltorn (ha ett schema för att alltid ha en spelare i tornet), pilot (planet tenderar att flyga svajjigt annars), luften tar en längre väg på vingens välvda yta vilket skapar ett undertryck, ni fattar, generella saker för hur alla flygplan flyger). MSF:Core beskriver vad vi skall tänka på när vil bemanna projekt, hur vi ser på Program Managment, Projekt Management (inte en snubbe som springer runt och frågar hur många % man har kvar på några workitems), Risk management, att alla individer i projektet är lika viktiga och hur vi undviker hierarkiskt styrda projekt mm. Ett desciptive (beskrivande) ramverk kännetäcknas av att det ser på objeket utifrån, med ett betraktande perspektiv. Ungefär som vi kollar på renen i den där jul-leksaksbubblan som det snöar i när man skakar om den... MSF:Core ser på SDLC och kommer med best-practices och beskriver sånt som funerat bra i projekt internt på Microsoft... Kanon!!!

Själva processen eller metoden instansierar vi genom att välja vilken metod vi vill köra (se MSF:Core som en abstrakt basklass som innehåller generella råd, tips och best practices för mjukvaruprojekt och VSTS som en spelare som instansierar och jackar in sig mot den verkliga klassen (MSF:Agile, MSF:CMMI, MSF:Scrum), som kopplar på process/metod stöd enligt nedan;

MSF_Core ligger dock i botten för alla dessa och det mesta av detta (nästan det bästa) kommer ni inte att springa på när ni nyinstallerat VSTS och TFS. Det ni ser där är den skapade metod-instansen (med MSF:Core i botten) som VSTS jackar in sig emot. I de flesta projekt jag kört där jag lyckats lyfta "andan" och energinivån i projektet har jag tillämpat MSF:Core's grundprinciper (ett exempel var det stora klädföretaget). MSF:Scrum, MSF:Agile är alltså metod/processtödet som kopplas på den generella MSF:Core "andan". Detta gör att det går lysande att köra MSF:Core med Scruminriktning (vanligt internt på Microsoft (fråga det coola Jolt (WPF) teamet)) eller någon annan variant (MSF:Agile, MSF:CMMI). Denna metod/process implementation av MSF har nu helt plötsligt gått från att vara descriptive till att vara prescriptive (vad är nu detta???). Jo, nu betraktar vi inte längre objektet (SDLC) utifrån utan flyttar oss in i smeten och ger konkreta råd och stöd för HUR vi skall arbeta. Kopplat till flyg-grejjen blir detta publikationer som beskriver hur vi flyger ett specifikt plan t.ex. JAS (militärt) eller hur vi flyger en MD-80 (passagerarplan). Förhoppningsvis är det bara aktuellt att gå igenom hur man genomför barrelrolls med ett JAS plan och inte med en MD80 t.ex... I fallet MSF:Scrum är det hur man jobbar med Product, Sprint backlocks, Sprint reviews, Sprint retrospectives och annat som är livsviktigt när man kavlar upp byxbenen, armarna (och allt annat som går att kavla upp...) och går in i projektrummet för att göra "riktigt" arbete...

Ville med detta inlägg bara visa kartan för MSF. Nästa entry kommer köra igång med grunderna i MSF:Core.

Ha en underbar dag i MSF-land! ;-)

ps. Dag König, min kära evangeliserande kollega på Microsoft gav MSF en fet spark i magen (och några andra känsliga områden) häromdagen genom att kalla det Microsofts svar på RUP... Dag, jag tycker du är lysande men nu får du ta och be MSF om ursäkt... Du skrämmer bort våra användare... :-) Hmmm... När jag tänker på det så är det rätt kul, en evangelist som svär i kyrkan... ;-) ds.