Mikael Deurell : MSF

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... ;-)

MSF Agile - Sommarkollo

mikaeld — Tue, 14 Aug 2007 17:59:00 GMT

Vill bara säga tack till alla deltagare på dagens sommarkollopass om MSF Agile. Om ni vill läsa mina inlägg om MSF Agile kan ni koppla på "jag vill bara läsa MSF och inte allt annat dravel" filtret genom att klicka på http://blogs.msdn.com/deurell/archive/tags/MSF/default.aspx. Presentationen kommer att finnas tillgänglig på http://www.microsoft.se/utbildningswebben (eller dra ner den härifrån på en gång om ni inte pallar att vänta :-))

Fridens liljor!
/Micke

Ny "Team Development with TFS" bok från P&P - Och, ja den är gratis!

mikaeld — Mon, 06 Aug 2007 23:00:00 GMT

En lyckad TFS implementation har mycket att göra med utbildning... För att få TFS att rocka i projekten krävs det enligt mina högst ovetenskapliga empiriska studier:

1. Att man har minst en person i varje team som kan hantera TFS på ett lite råare sätt än "mes-GUI" mode.
2. Att man inte gör saker krångligare än vad de är ("vi är väääldigt speciella och måste ha branches i fem nivåer...")
3. Att teamet läser in sig på hur TFS fungerar och hur detta effektivt kan mappas mot företagets arbetssätt

Ni bör inte:

1. Ha en centralt placerad, mindre begåvad, nervös människa bakom TFS spakarna som sköter alla merges (RI/FI) och får spel varje gång det poppar upp en varning eller ett fel.
2. Ähhh, struntar i den. Undvik bara punkt 1 så är det lugnt!

Vilken tur att våra hjältar på P&P har släppt en lysande bok som ni gratis kan ladda ner (gör det pronto!) med:

- Branching Guidelines
- Project structures (ASP.net / .not / .net)
- PM
- Reporting

Lysande! Ladda ner från codeplex!

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!!! :-)

Dagens MSF:agile Workshop

mikaeld — Tue, 27 Mar 2007 21:53:00 GMT

Vill bara påminna mina deltagare från förmiddagens MSF-workshop om att presentationen finns här! Vill ni ha tillgång till extramaterialet är det bara att kontakta mig så fixar jag det... Tack för en trevlig förmiddag!!!

I'll be talking at Developer Summit 2007

mikaeld — Tue, 06 Mar 2007 14:16:00 GMT

I got a mail last night confirming my speaker slot at Developer Summit 07. My session will be the last one on day two and I’ll talk about ”How to build high performance teams with MSF!”. I’ll go through the advocacies and roles in MSF from a team perspective, covering the MSF:agile engine, team interaction and also cover Readiness Management based on MSF, Microsoft Best Practices from our product teams and my own experiences from the field… Lots of fun! See you there!

Tonight make me unstoppable
And I will charm I will slice I will dazzle them with my wit
Tonight make me unstoppable...

Everyone is a friend in the agile community... Right...

mikaeld — Sun, 04 Mar 2007 12:24:00 GMT

Is it just me, or are you also getting really tired of this?

It would be really funny if other communities did the same thing over such a lame #¤"% thing as process, ehmm, frameworks, ehm... philosophy... Shouldn't this be all about practice? I love this business! Geek nirvana! :-)

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…

Mer jävlaranamma i projektteamen!!!

mikaeld — Mon, 26 Feb 2007 12:15:00 GMT

En av de stora anledningarna att många projekt aldrig får någon teamkänsla är att de... Inte jobbar ihop! Projektledaren jobbar med hjälp av någon magisk multiplexingalgoritm för att få projektmedlemmar att snurra runt på tre/fyra olika projekt istället för att kraftsamla och LEVERERA ett innan man kör igång något nytt. Tror någon att detta springande är effektivt? Att man vinner tid? Pengar? Varför ser det ut så här på så många ställen?

Tänk er en insats av ett specialförband långt bakom någon hårig fiendes linjer. Det är mörkt... kallt... alla är trötta efter en veckas frammarsch... Signalistsnubben är grymt deppig, han har ont i hela kroppen och har precis tryckt i sig sin sista sura nickel (Den äckliga svarta som man får näsblod av)... Men, rutinerna sitter, alla gör sin uppgift och hjälper gruppen när något oförutsett händer... Målet är i sikte... Prickskytten andas lugnt... Reser sig sakta, sakta upp och säger... "Nä, nu måste jag jitta, det strular lite i ett annat uppdrag där jag är inne på 12% och jag kan bara hänga här på 62%! Toodiloo! Jag är tillbaks på fredag. Skjut inte någon innan jag är tillbaks!"...

Vad Micke undrar: "Varför tillåter man detta när det konstant sänker leveranshastighet (på alla projekten), teammoralen, samt stressar ##¤%¤ ur projektmedlemmarna?"

Jag jobbade ett bra tag som teamledare för ett gäng arkitekter på ett konsultbolag. Grymt bra företag, otroligt duktiga konsulter. Sociala, smarta, diplomatiska... Precis som det står i alla rekryteringsannonser. Någonting fick mig dock att fundera en hel del, alla anställda skulle ut och leka någon slags macho-version av "The Human Element". Ni vet, käka fryst kyckling kryddad med tallbarr och bada vak någonstans i skärgården, frystorka sina kläder, ge varandra "rak" feedback i form av hårda kommentarer som gjorde att 10% av de som var med på kursen ville simma tillbaks till fastlandet med gråten i halsen och en krossad självbild inlindad långt nere i magsäcken, bredvid några bitar fryst kyckling... Fattade aldrig varför man skulle göra detta, det var ju inte så att vi skulle storma någon ö... Vi var 50 datanördar med en himmelsk massa högskolepinnar som ville göra ett bra jobb! Tillsammans!!! Inga soldater... Samtidigt som detta händer åkte företagets VD runt och höll föredrag om "hur man skapar högpresterande team", när det inte fanns ett enda på hela firman... Inte mitt team heller... Det var högpresterande individer, samlade i team... Det är inte ett högprestrande team, det är högpresterande människor, samlade i grupp...

Vad Micke har lärt sig: För att skapa högpresterande team måste man jobba NÄRA tillsammans, aktivt skapa en kultur där alla vågar vara öppna med sina svagheter och styrkor. Få teammedlemmarna att hugga uppgifter som ligger 5% över vad de skulle hugga i vanliga fall, få teammedlemmar att våga ta kontrollerade risker och utmana sig själva istället för att pösa tillbaks i fotöljen. Ett steg i detta är att pressa fram teamet i FIRO modellen, dock utan fryst kyckling och vakbad... Men genom att... Jobba ihop, med saker som får projektet framåt!!! (Oftast inte att äta fryst kyckling...). En härlig sak är att i ett högpresterande team behöver inte alla teammedlemmar vara högpresterande, det är nästan bättre om så inte är falltet. Mixen är viktigare... Cool!

Ett sätt som jag sett fungera i verkligheten, och som löser detta är att använda "feature teams". I vissa projekt kanske hela projektet är ett feature team medan i andra fall så är det ett subset som levererar en specifik feature till huvudprojektet. Ett team som hugger ett eget rum, får en privat branch för sin källkod. Kommer överens om en quality gate för att definera när man är klar och kan köra en reverse integration mot main trunken...Processen ser ut såhär...

Forward integrate är att trycka ut nya saker från main-trunken till vår privata branch, och reverse integrate är det motsatta (Merga med trunken när aktuell feature är klar...).

Att hålla tiden nere för en featureleverans gör att man kan koncentrera sig på att leverera en feature, splitta teamet (om det behövs) och snabbt hugga nästa uppgift. Jag struntar helt i att göra jämförelser till agila metoder i detta fall... Funkar faktiskt för de flesta projekt och processer... Ställ teamen på tårna istället för att se dem försvinna springandes i korridorerna för att hinna runt till alla sina 5 "delprojekt" som alla går över tiden...

Kör så det ryker!!!!

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 2. Teamet

mikaeld — Tue, 23 Jan 2007 20:44:00 GMT

Ok, I sann MSF anda attackerar vi den största risken först! Utan att fega ur! Teamet... ;-) För att underlätta för kunskapstörstande MSF aktivister slog vi ihop våra feta huvuden på Microsoft och brainstormade ihop namngivningen för vår nya teammodell... Vi hade ett otroligt bra läge när vi ändå kom överens om att fimpa MSF 3.0 rollerna (eller utveckla...). Att modellen är baserad på vår egen var givet, behövde bara anpassas och... förtydligas... förenklas... bli enkel att översätta till olika språk... Här kommer ordlistan för denna post;

- Advocate [Förespråkare/Representant]
- Advocacy ["Förespråkar/representantgrupp"]]
- Advocacies ["Förespråkar/representantgrupper"] (finns ingen direkt översättning)
- Constituencies [Valkretsar]

Ok, jag erkänner, vi misslyckades... Katastrofalt! Teammodellen rockar! Den har räddat mig många gånger, men namngivningen...

Allvarligt så är detta väldigt tråkigt. Det betyder att intresserade människor spenderar alldeles för mycket tid med att förstå vad "#¤%¤ som menas istället för att agera, tråkigt... För att försöka förtydliga detta och få fram det otroligt kraftfulla budskapet i teammodellen kommer här unge herr Deurells förklaring på hyffsat ren svenska...

Det som står i de grå rutorna är våra Advocacies som defineras i MSF:Core, på hyffsat ren svenska är detta en roll som skall representeras (i någon form) i projektgruppen. Det som står utanför (med gubbarna i) är hur denna implementeras i MSF:Agile (framework->process ni kommer väl ihåg) och kallas i MSF:Agile för Roles. Det man genast ser är att MSF:Agile kombinerar UX och PM Advocacies i en Business Analyst roll. En Advocacy representerar en Constituency (en valkrets). Detta är på hyffsat ren svenska en mekanism som säger att varje roll representerar en krets utanför projektet, t.ex. The Project Stakeholder (De som degar upp) eller The Business Sponsor (Kunden). Detta för att projektet skall kunna ta sunda beslut och inte köra med klassiska "vi är världen" projekt-skygglappar. En klassisk miss i många projekt är att Program Managment (som representerar de som betalar) är samma person som Product Management (som representerar kunden). Detta leder till en aningen schitzofren situaltion där man får slåss med sig själv. Product Management skall ju slåss för att ge kunden allt som finns prioriterat i "product" backloggen medan Program Management skall stå för konststycket att leverara detta på utsatt tid och peng... Ofta motstridiga åsikter. Kunder får alltid mest om detta blir en ge och ta dans... MSF hävdar att om samtliga Advocacies inte är representerade i projektet kommer projektet att misslyckas... I någon form...

Jag kommer att återkomma till varje enskild roll i en dedikerad post så detta är mest en översikt...

Program Managment
Mål: Att leverera projektet inom de begränsningar som råder (tid, budget)
Funktioner:
- Project management (Inte en person som aldrig skrivit en kodrad och som kutar omkring och frågar hur många procent man gjort klart sedan igår utan en vallhund som leder och håller ihop teamet samt håller vargen borta)
- Solution architecture
- Process assurance (Förfina och anpassa processen/metoden som används vartefter teamet lär sig mer om sig själva, projektet och kunden)
- Administrative services (Göra livet lätt för teamet)

Product Management
Mål: Göra kunden nöjd!
Funktioner:
- Business value (Alltid leverera det som ger mest värde först, enligt den prioriterade Scenario/QoS "product" backloggen.
- Marketing (Intern marknadsföring för att stärka teammoralen, fixa fikakoppar med projektnamnet, hitta på cool callsign för projektet mm. Underskatta inte vikten av detta!)
- Customer advocacy (Altid slåss för kunden!)
- Product planning

Development
Mål: Bygga lösningen bit för bit.
Funktioner:
- Technology consulting
- Implementation unit testing and design
- Application development

Architecure
Mål: Vägleda projektet ur ett arkitekturperspektiv
Funktioner:
Solution consulting
Implementation architecture and design (Shadow architecture, leading shadow, trailing shadow)
Infrastructure design and development

Test
Mål: Kontinuerligt övervaka och rapportera produktens kvalitet.
Funktioner:
Test planning
Test engineering
Test reporting

Release Management
Mål: Ansvara för att produkten kan deployas vid slutet av varje iteration och ansvara för build management.
Funktioner:
Infrastructure
Support
Operations
Logistics
Build Management
Commercial release management

User Experience
Mål: Förbättra användbarheten
Funktioner:
Accessibility
Internationalization
User advocacy
Training/support material
Usability research and testing
User interface design

Phew! Har ni läst hit bjuder jag på en öl! Det viktiga att ta med sig är att genom att personer i projektet tar på sig en eller fler Advocacies och att alla dessa täcks in, kommer alla Constituencies (viktiga grupper utanför projektet) att representeras i alla beslut som tas vilket leder till... bättre beslut... En person kan både representera Development och Architecture (en vanlig kombination) men vissa kombinationer är hjärndöda (tex. project management och product man enligt resonemanget ovan), återkommer till detta! Var så säker ;-)

We took a back road.
We're gonna look at the stars.
We took a backroad in my car.
Down to the ocean,
it’s only water and sand
And in the ocean we'll hold hands.