<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>Sterk blanding &#187; Rikard Eriksen</title>
	<atom:link href="http://sterkblanding.no/blog/author/steriarikard/feed/" rel="self" type="application/rss+xml" />
	<link>http://sterkblanding.no</link>
	<description>– Sterke meninger om IT og ledelse</description>
	<lastBuildDate>Tue, 08 May 2012 11:48:44 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	
		<item>
		<title>Et godt retrospektiv</title>
		<link>http://sterkblanding.no/blog/2011/05/26/et-godt-retrospektiv/</link>
		<comments>http://sterkblanding.no/blog/2011/05/26/et-godt-retrospektiv/#comments</comments>
		<pubDate>Thu, 26 May 2011 18:46:49 +0000</pubDate>
		<dc:creator>Rikard Eriksen</dc:creator>
				<category><![CDATA[Samhandling]]></category>
		<category><![CDATA[Smidig]]></category>
		<category><![CDATA[samarbeid]]></category>
		<category><![CDATA[scrum]]></category>

		<guid isPermaLink="false">http://sterkblanding.no/?p=1165</guid>
		<description><![CDATA[Retrospektiv er en av de tre seremoniene i Scrum, og kanskje den viktigste. På retrospektiv evaluerer vi iterasjonen som har vært. Vi snakker om hva som har fungert godt, hva vi skal ta med oss videre og hva vi skal fortsette å gjøre. Og vi diskuterer hvor vi trenger å forbedre oss, hva vi skal [...]]]></description>
			<content:encoded><![CDATA[<p>Retrospektiv er en av de tre seremoniene i Scrum, og kanskje den viktigste. På retrospektiv evaluerer vi iterasjonen som har vært. Vi snakker om hva som har fungert godt, hva vi skal ta med oss videre og hva vi skal fortsette å gjøre. Og vi diskuterer hvor vi trenger å forbedre oss, hva vi skal endre på og hva vi skal slutte å gjøre.</p>
<p><span id="more-1165"></span></p>
<p><strong>Rutinepreget evaluering</strong><br />
Å evaluere seg selv er selvsagt viktig også i andre prosesser enn Scrum. Det å stadig forbedre seg, for å kunne jobbe mer effektivt, levere bedre kvalitet og trives bedre som team, er en nøkkelfaktor for suksess i de fleste prosjekter. Dessverre kan retrospektivmøter etterhvert bli rutinepregede; En aktivitet man gjør iterasjon etter iterasjon, uten egentlig å få fram de tingene som betyr noe, eller tenke nytt om temaer som går igjen gang etter gang. Da kan det ofte hjelpe å bryte opp mønstrene og gjøre noe nytt, for å skape variasjon og nytt engasjement rundt retrospektivet.</p>
<p>Her er et referat fra et retrospektiv jeg nylig hadde sammen med teamet jeg er Scrum Master på. Kanskje kan disse øvelsene inspirere deg til å skape ny glød neste gang du skal delta på et retrospektiv.</p>
<p><strong>Første øvelse: Tidslinja</strong><br />
Først tegnet vi opp ei tidslinje som illustrerte de tre ukene som iterasjonen hadde vart. Det var ei rett linje med helgene og andre fridager markert. På denne linja tegnet vi inn viktige hendelser. For eksempel måtte vi i slutten av første uke endre løsningsbeskrivelsen på flere av oppgavene på iterasjonskøen, fordi de var basert på en forutsetning som viste seg å være feil. I uke to måtte vi gjøre noen uplanlagte feilrettinger på en tidligere leveranse, og i uke tre fikk vi et nytt medlem på teamet.</p>
<p>Dette er noen eksempler på ting som kan tegnes inn på tidslinja. Det er ingen regler for hva som er riktig eller feil å tegne inn. Stort og smått kan tas med. Poenget med denne øvelsen er rett og slett å friske opp hukommelsen til teamet. Vi hjelper hverandre med å huske hva vi skal evaluere.</p>
<p><strong>Andre øvelse: Happygraf</strong><br />
Under tidslinja fikk så hvert teammedlem anledning til å tegne sin Happygraf. En Happygraf er en kurve som viser hvor fornøyd/glad eller misfornøyd vedkommende har vært i løpet av iterasjonen. Jo høyere kurve, jo mer fornøyd er du. Skalaen bestemmer dere selv. Dette er en morsom måte å uttrykke hvordan du har hatt det de siste tre ukene. Og det gir en fin innfallsvinkel til å kommunisere om følelser, uten å bruke ord.</p>
<p><strong>Tredje øvelse: Stikkordslotto</strong><br />
I den siste øvelsen fikk hvert teammedlem utdelt grønne og røde lapper. På de grønne lappene skrev vi ting som hadde fungert godt i iterasjonen, ting vi ville fortsette med å gjøre. På de røde lappene skrev vi forbedringspunkter, ønsker om endring. Her brukte vi stikkordsform, slik at vi bare skrev et ord eller et uttrykk på hver lapp. Setninger var forbudt.</p>
<p>Deretter samlet vi inn alle lappene og blandet dem sammen. De grønne lappene i en haug, og de røde i en annen. Så trakk vi etter tur en og en lapp fra en bunke, og leste stikkordet på den høyt. (Fikk vi en av våre egne lapper la vi den tilbake og trakk en ny.) Den som trakk en lapp måtte prøve å tolke hva stikkordet betydde. Da kunne hun gjerne bruke sine egne erfaringer fra iterasjonen til å forklare hva vedkommende hadde ment, og hva hun selv ville legge i ordet.</p>
<p>Etter at hun hadde sagt hva hun tenkte stikkordet betydde, skulle den som hadde skrevet lappen forklare hva han egentlig hadde ment. På denne måten fikk vi minst to forskjellige vinklinger på samme tema, og svært ofte gode diskusjoner som følge av det. En av oss hadde samtidig rolle som sekretær, og førte et referat av hva som ble sagt.</p>
<p><strong>Tiltak og ambisjoner</strong><br />
Sammen fikk disse tre øvelsene fram flere lærdommer  fra de siste ukene. Vi diskuterte flere vinklinger enn vi tidligere har gjort på samme tema, og gravde dypere i noen enkeltsaker. Til sammen brukte vi ca to timer på øvelsene. Vi kombinerte det med lunch, og hadde kjøpt inn mat.</p>
<p>I begynnelsen av den påfølgende iterasjonen tok vi en gjennomgang av referatet fra retrospektivet. Vi valgte ut de tre viktigste punktene hvor vi ønsket å sette oss konkrete mål for forbedring. Vi ble enige om tiltak og ambisjoner for hvilke resultater vi ønsket å oppnå. Denne gjennomgangen brukte vi ca en time på.</p>
<p><strong>Dine erfaringer</strong><br />
Hvilke erfaringer har du med retrospektiver? Har du opplevd noe som har fungert spesielt godt, eller har du tips til øvelser som er morsomme og gir gode resultater?</p>
]]></content:encoded>
			<wfw:commentRss>http://sterkblanding.no/blog/2011/05/26/et-godt-retrospektiv/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Lean eller agile, hva passer best for deg?</title>
		<link>http://sterkblanding.no/blog/2010/05/24/lean-eller-agile/</link>
		<comments>http://sterkblanding.no/blog/2010/05/24/lean-eller-agile/#comments</comments>
		<pubDate>Mon, 24 May 2010 16:11:21 +0000</pubDate>
		<dc:creator>Rikard Eriksen</dc:creator>
				<category><![CDATA[Samhandling]]></category>
		<category><![CDATA[Smidig]]></category>
		<category><![CDATA[Uncategorized]]></category>
		<category><![CDATA[Agile]]></category>
		<category><![CDATA[Lean]]></category>
		<category><![CDATA[scrum]]></category>

		<guid isPermaLink="false">http://sterkblanding.no/?p=575</guid>
		<description><![CDATA[Lean og Agile er to prosesser som ofte blir plassert i samme bås, som &#8220;smidige&#8221; måter å jobbe på. Men selv om de har mange likhetstrekk, er sannheten at de er to veldig forskjellige tilnærminger til veldig forskjellige problemstillinger, og har sine opphav i helt ulike kulturer. Lean kommer fra en asiatisk kultur, der det [...]]]></description>
			<content:encoded><![CDATA[<p><a href="http://en.wikipedia.org/wiki/Lean_software_development">Lean</a> og <a href="http://en.wikipedia.org/wiki/Agile_software_development">Agile</a> er to prosesser som ofte blir plassert i samme bås, som &#8220;smidige&#8221; måter å jobbe på. Men selv om de har mange likhetstrekk, er sannheten at de er to veldig forskjellige tilnærminger til veldig forskjellige problemstillinger, og har sine opphav i helt ulike kulturer. <span id="more-575"></span></p>
<p>Lean kommer fra en asiatisk kultur, der det kollektive og prosessen i seg selv er det sentrale. Lean er laget for å strømlinjeforme en spesiell måte å løse en kjent oppgave på. Agile på sin side kommer fra USA, der individet fremheves over alt annet (<a href="http://agilemanifesto.org/">&#8220;Individuals and interactions over processes and tools&#8221;</a>). Agile er først og fremst en effektiv måte å jobbe på når vi ikke kjenner veldig godt til omfanget og innholdet i oppgaven, og er nødt til å finne veien samtidig som vi går den.</p>
<p>I et foredrag på <a href="http://www.scan-agile.org/">Scandinavian Agile Conference</a> 2009 presenterte <a href="http://en.wikipedia.org/wiki/Jim_Coplien">Jim Coplien</a> disse 9 punktene der Lean og Agile er motstykker:</p>
<table>
<tr>
<th>Lean</th>
<th>Agile</th>
</tr>
<tr>
<td>Invitasjonsbasert</td>
<td>Inkluderende</td>
</tr>
<tr>
<td>Tenke</td>
<td>Gjøre</td>
</tr>
<tr>
<td>Feed forward</td>
<td>Feedback</td>
</tr>
<tr>
<td>High throughput</td>
<td>Low latency</td>
</tr>
<tr>
<td>Monokromisk, planlagt</td>
<td>Polykromisk, reaktiv</td>
</tr>
<tr>
<td>Utvikle modeller av verden</td>
<td>Dele modeller av verden</td>
</tr>
<tr>
<td>Prosess</td>
<td>Mennesker</td>
</tr>
<tr>
<td>Håndtere kompliserte problemer</td>
<td>Håndtere komplekse problemer</td>
</tr>
<tr>
<td>Standardisere</td>
<td>Inspect and adapt</td>
</tr>
</table>
<p>En gjennomgang av disse punktene kan være tema for et senere innlegg. Det jeg vil presentere denne gangen, er to praktiske øvelser som illustrerer noen av forskjellene og styrkene ved Lean og Agile. Øvelsene tar ca 5 minutter hver.</p>
<h1>Øvelse 1: Agile</h1>
<p>Finn en gruppe på ca 10-15 personer, og la de stå i et åpent område som de kan bevege seg rundt i. Hver person skal tenke på to andre personer i gruppa. Når alle har valgt ut sine to personer (uten å avsløre til noen hvem de har valgt), så er oppgaven som følger: Hver og en person skal nå plassere seg slik i rommet at han eller hun har nøyaktig like stor avstand til de to personene vedkommende tenkte på.</p>
<p>Før de får begynne å løse oppgaven, så er dette et morsomt spørsmål å stille til eventuelle prosjektledere i rommet: Hvis man skulle benytte klassisk prosjektledelse til å lede gruppa i denne øvelsen, hvordan skulle man gå frem da? Hvilke planer og retningslinjer kunne man lage som ville hjelpe dem fram til et raskt og godt resultat? De fleste vil snart komme fram til den konklusjonen at det er en ganske vanskelig (kompleks) oppgave.</p>
<p>Om vi benytter Scrum som eksempel på en smidig måte å løse dette på, hva ville en god Scrum master eller coach da si? Bare gjør det! Vi lar gruppa være selvorganiserende, og lar hvert enkelt individ ta ansvar for å på en selvstendig måte løse sin del av oppgaven, men i tett samarbeid med de andre i gruppa. Resultatet vil bli at etter en kort tid med tilsynelatende kaotiske og uorganiserte bevegelser, vil alle ha funnet likevektspunktene sine som til sammen løser oppgaven. Et resultat som ville være svært mye mer krevende å oppnå med en sentralt styrt prosess.</p>
<h1>Øvelse 2: Lean</h1>
<p>Hva så med Lean, hvordan kan det illustreres ved hjelp av en øvelse? Her trenger vi litt færre personer, ca 10 er fint. Gi en tilfeldig person i gruppa en gjenstand han kan holde i handa (ei tom flaske er et godt alternativ), og presenter dem for følgende utfordring: Gjenstanden skal nå sendes fra person til person i alfabetisk rekkefølge basert på fornavn. Det skal skje så raskt som mulig, og de vil bli tatt tiden på!</p>
<p>Ved første forsøk vil gruppa bruke litt tid på dette. De må fortelle navnene sine for å finne riktig rekkefølge. De vil typisk bruke et halvt til to minutter på å bestemme rekkefølgen og sende gjenstanden rundt. Fortell dem resultatet, og spør så om de kan gjøre det igjen, raskere. Det vil de naturlig nok klare, etter som de nå bedre kjenner navnene til hverandre.</p>
<p>Etter å ha fortalt dem tiden for forsøk nummer to, la dem forsøke en gang til, og be dem tenke på måten de står plassert på. De vil oppdage at det å stå på rekke eller i en sirkel, i alfabetisk rekkefølge, vil gjøre det enklest mulig å sende gjenstanden fra person til person. Vi <a href="http://en.wikipedia.org/wiki/Lean_software_development#Eliminate_waste">eliminerer waste</a>!</p>
<p>Hvor raskt er det mulig å klare det? Om de står i en tett sirkel, og hver enkelt så vidt berører gjenstanden før nestemann gjør det, kan de klare øvelsen på under et sekund. Det vil være en ganske dramatisk forbedring fra det første forsøket! Det viser hvor effektiv Lean kan være på denne typen oppgaver.</p>
<h1>Oppsummering</h1>
<p>Lean og Agile er laget for å løse forskjellige typer oppgaver. De kommer fra forskjellig bakgrunn, og selv om de virker like, så skiller de seg vidt fra hverandre på noen sentrale områder. Øvelsene over demonstrerer noen av de spesielle styrkene til de to prosessene. Disse styrkene er det viktig å huske på når man skal velge tilnærming til et prosjekt eller andre arbeidsoppgaver som krever en god prosess.</p>
<p>Hvilke erfaringer har du som leser gjort deg med Lean og Agile? Har du opplevd oppgaver eller prosjekter der de har passet spesielt godt eller spesielt dårlig?</p>
]]></content:encoded>
			<wfw:commentRss>http://sterkblanding.no/blog/2010/05/24/lean-eller-agile/feed/</wfw:commentRss>
		<slash:comments>4</slash:comments>
		</item>
	</channel>
</rss>

