Frukostseminarium 4/11 - 2009
Genom att införa det agila ramverket Scrum och kombinera det med nödvändiga utvecklarpraxis kommer man långt i fråga om snabbhet, flexibilitet och kvalitet. Men för att verkligen bli framgångsrika behöver vi utveckla vår förmåga att skapa framgångsrika team av specialiserade individer.
I denna presentation får du veta mer om vad ett införande av Scrum kan förväntas medföra för teamets arbetssätt och tips om metoder att få till en bra team-känsla.
Mikael Boman - Citerus
1. Utveckla teamet och bli en Scrum Developer
Vad behöver ditt team för att dra full nytta av Scrum?
Mikael Boman, Citerus AB
mikael.boman@citerus.se
018-430 18 20
citerus.se
1
2. Citerus - Mikael Boman, 2009 - mikael.boman@citerus.se - 0709-43 90 80
Om Citerus
• Citerus är ett konsult- och utbildningsföretag som hjälper sina kunder att lyckas med
mjukvaruutveckling. Sedan 1996 har vi utvecklat mjukvara, lett projekt, förbättrat
utvecklarpraxis och förfinat ledningsmetoder åt företag från många olika branscher. Vi uppnår
resultat genom att höja kvalitetsribban, sätta människor i första rummet och minska på
byråkratin.
Om Mikael Boman
‣ Konsult sedan 1996, utvecklare, projektledare, rådgivare/coach
‣ Medlem i expertgruppen för JSR-296, Swing Application Framework
‣ Arbetat med Scrum sedan 2003
‣ Arbetat med skilda branscher och storlekar på organisationer, t.ex. Lantmäteriverket, bwin, Dirac Research, SEB, SF Bio, ICA,
Eniro, m.fl.
‣ Certified Scrum Trainer, Scrum Alliance.
2
3. Citerus - Mikael Boman, 2009 - mikael.boman@citerus.se - 0709-43 90 80
Agenda
Team
Fokus
Förtroende
Lärande
3
4. No group ever becomes a team until it
can hold itself accountable as a team.
Från "The Wisdom of Teams" av Jon Katzenbach och Douglas Smith
4
5. Citerus - Mikael Boman, 2009 - mikael.boman@citerus.se - 0709-43 90 80
Grupp eller team?
Foto från sxc.hu
5
6. Citerus - Mikael Boman, 2009 - mikael.boman@citerus.se - 0709-43 90 80
Gemensamt mål/syfte
Foto från sxc.hu
6
7. Citerus - Mikael Boman, 2009 - mikael.boman@citerus.se - 0709-43 90 80
Gemensamt ansvar
Foto från sxc.hu
7
9. Citerus - Mikael Boman, 2009 - mikael.boman@citerus.se - 0709-43 90 80
Tvärfunktionellt och självorganiserande
Foto från sxc.hu
9
10. Citerus - Mikael Boman, 2009 - mikael.boman@citerus.se - 0709-43 90 80
Rätt storlek
"Why Individuals in Larger Teams Perform Worse." - Jennifer S. Mueller, University of Pensylvania
10
11. Citerus - Mikael Boman, 2009 - mikael.boman@citerus.se - 0709-43 90 80
Tid
Forming
Storming
Norming
Performing
Bruce Tuckman, 1965
Foto från sxc.hu
11
12. There's scientific evidence that multitasking
is extremely hard for somebody to do,
and sometimes impossible
David Meyer, professor i psychologi vid University of Michigan
12
13. Citerus - Mikael Boman, 2009 - mikael.boman@citerus.se - 0709-43 90 80
Fokus - på individnivå
Max två uppgifter samtidigt
Ett team i taget
Foto från sxc.hu
Cognitive control in media multitaskers. - Ophir, E., Nass, C. I., & Wagner, A. D., Stanford University, 2009 13
14. Citerus - Mikael Boman, 2009 - mikael.boman@citerus.se - 0709-43 90 80
Fokus - på teamnivå
Inga störningar under sprinten
Vid behov: korta sprinten
Vid behov: problemlösarteam
Foto från sxc.hu
14
15. Groups that avoid conflict won't
be able to face tough issues or
handle the creative conflict that
generates new ideas.
Esther Derby, ledarskapskonsult
15
16. Citerus - Mikael Boman, 2009 - mikael.boman@citerus.se - 0709-43 90 80
Förtroende
Informera
Alla behöver höras
Lita på varandras kompetens
Självbestämmande
Håll det du lovar
Foto från sxc.hu
16
17. I didn’t fail 10,000 times.
I found 10,000 things that don’t work.
Tomas Edison, om sitt arbete med att hitta rätt material för glödtråden i glödlampor
17
18. Citerus - Mikael Boman, 2009 - mikael.boman@citerus.se - 0709-43 90 80
Ständigt lärande
Demo ≠ tillfälle för beröm
➡ Demo = uppvisning av status
Fundera på belöningssystemen
Sluta aldrig med återblickarna
A minute to learn,
a lifetime to master
Foto från sxc.hu
18
Går igenom en del saker som behövs för att kunna få till ett högpresterande team- Mycket är generellt för alla former av teambyggande, men jag fokuserar på det som jag sett som varit viktigt för de team som faktiskt blivit högpresterande och vilket stöd vi faktiskt redan har för mycket av detta i Scrum-ramverket - bara vi är noga med att tänka på vissa detaljer Frågor - när som helst
Tillåt alla att fokusera - Etablera gemensamt ansvar - Skapa en miljö av förtroende - Var noga med kontinuerlig förbättring och ständigt lärande
trasiga fönster som Magnus pratade om
Man kan jobba i grupper, men också i lag/team. Det som kännetecknar ett team är ett antal saker - och vill man få framgångsrika Scrumteam så behöver man se till att detta funkar.
Ganska lätt att uppnå i projekt, men viktigt att basera detta på en bra och tydlig vision från Produktägaren om vart man vill med sin produkt - detta ger möjlighet för teamets medlemmar att bli engagerade. Visionen kan vara uttryckt på flera sätt, några exempel är: - hiss-pitch - produkt-låda - press release Detta kan låta lite oseriöst och larvigt, men kan göra stor effekt för att hela iden ha en tydlig vision att luta sig mot.
Jobbar vi med Scrum, jobbar vi också med commitment på teamnivå . Dvs vi kan aldrig komma undan med att ”vi kodade klart , men testarna gjorde inte sitt jobb”. Det är teamet som ska hjälpas åt att lösa detta. Viktigt att ScrumMasters som faciliterar planeringen ser till att alla hörs, och inte bara den dominerande personen.
Tydlig med vilka regler som gäller. Det behöver inte vara en manual klar för precis allt, men det ska vara tydligt hur vi hantera oklarheter. Tittar vi på Scrum så är det inte mycket som är uppstyrt (några möten osv), men det som gäller ska vara tydligt hur vi tar fram beslut för nya situationer. Då kan vi hantera alla saker som uppkommer utan att ha fullständiga svar i förväg
Har alla kompetenser som behövs för att arbeta effektivt mot målet. Detta tar bort möjligheten att skylla ifrån sig, och ger möjligheten att känna att teamet lyckas tillsammans. Rätt att fatta beslut som rör teamet och teamets arbete. Skapar engagemang. Självklart kommer inte teamet alltid att tillsätta vilka individer som är med, de finns ibland en linjechef som gör detta. Men väldigt mycket annat kan teamet styra, och ger man dem chansen så kommer det ofta att gå väldigt bra.
Detta har ni säkert hört/sett om ni lärt er något om Scrum, men det tål att upprepas, då många Scrumteam är upp till 10 personer. Det är sällan ett recept för högre produktivitet som team. Ska vara 7+-2, en del forskning säger att optimalt är 6-7.
Det krävs tid för att bygga relationer inom gruppen. Detta behövs för att få till ett öppet klimat för diskussioner. Detta leder till att vi ska vara försiktiga när vi ändrar i team-sammansättningar - det får effekter för effektiviteten. Forming=behöver ledare;Storming=kämpar om roller;Norming=Roller hittade;Performing=just det! En del säger 3-6 månader - men det finns många olika erfarenheter. Team building kan låta lite tråkigt, men kan göra att stegen genom processen att bli ett högpresterande team går fortare
Tillåt fokus på en till två uppgifter, gärna inom samma projekt. Att fokusera på endast en sak kan vara fel, om man blir uppehållen av hinder. Men mer än två och kvaliteten avtar. Svårare att värdera vad som är viktigt om man försöker multi-tasking (ny studie gjord på Stanford Univ) - ignorerar inget. Kan heller inte låta bli att tänka på det som de inte arbetar med just nu. Nämn bwin-exemplet. Vad lär vi oss då? Låt teamemedlemmar höra till ett team, inte fler. Det kommer att finnas specialistkompetenser som delas mellan flera team, men det kanske går att lösa så att man får jobba en hel dag i taget med ett team?
Viktigt att så långt det är realistiskt faktiskt skydda teamet från förändringar under sprinten. Här går engagemang och effektivitet ner väldigt fort om det kommer in nya styrningar kontinuerligt istf i de intervall som vi kommit överens om när vi började arbeta med Scrum - dvs till varje ny Sprint. Om man har en situation där man måste få saker gjorda snabbt - kosta ner sprintlängden. En vecka är helt OK - och har man massor av saker som inte kan vänta så länge kanske man får titta på att tillsätta ett problemlösarteam som jobbar på ett annat sätt - tex med en Kanban (se tidigare frukostseminarium).
Vi måste få till en miljö där saker kan diskuteras öppet för att nå vår fulla potential. Saker att tänka på: 1) dela information 2) se till att alla får höras (facilitera möten) 3) Lätt hänt att PO inte accepterar Engineering Practices -> teamet smyger in eget arbete -> problem. Tbx till gemensamt mål! 4) ge teamet självbestämmande. Om teamet inte löser sina egna problem, så är det fel i sammansättningen. 5) visa att vi faktiskt ska jobba med Scrum, (från organisation, PO osv) - håll det du lovar teamet (SM ska lösa de problem som han/hon åtar sig, PO ska inte komma och störa osv)
Vi kan inte slås ned av misslyckanden. Se t.ex. demon i Scrum. Den får inte vara till för att teamet ska få applåder, utan för att visa hur vi faktiskt ligger till och sen kunna diskutera i återblicken vad vi kan göra för att förbättra vårt arbetssätt. Belöningssystemen kan motverka lärande och att man vågar lyfta upp problem. Belöningar (bonusar, löneförhöjningar osv) kanske ska vara teambaserade istf individbaserade. Människor gör det som belönas. I Scrum har vi så bra stöd för återblickar. Problemet är att en del team tycker att de blir poänglösa efter ett tag: det är ju bara samma saker jämt. Det kan vara ett symptom på att fel som diskuteras aldrig åtgärdas, eller att fel som åtgärdas har en rot-orsak som i sin tur inte åtgärdas.
Frågor? Massor mer detaljer att lära. Ett tips på en bra bok som nästan garanterat ingen har läst är Mike Cohns nya bok om Succeeding with Agile, som handlar om hur man blir riktigt bra på att arbeta agilt. Han kommer också att köra en workshop på detta tema, bla i Sverige i vår. mer info om detta kommer på Citerus webbplats inom kort.