Posts Tagged ‘missförstånd’

h1

Mini-seminarie på Sogeti Sverige Alumni ikväll – ”Scrum – Myths, Misconceptions and Superstition”

torsdag, 10 februari, 2011

Ikväll kommer jag få äran att hålla ett kort mini-seminarie om Scrum på Sogetis Alumnikväll i Stockholm. Vinklen jag valt är ”Scrum – Myths, Misconceptions and Superstition”.

.


Sogeti Sverige Alumni är ett nätverk för dig som vill hålla kontakt med Sogeti och alla dina tidigare och kanske även framtida kollegor. På Alumnikvällar är man välkommen att träffa vänner och knyta nya kontakter samt få en spännande uppdatering om vad som händer på Sogeti.

Mini-seminariet kommer fångas på film och publiceras några dagar senare här på bloggen.

Kanske ses vi redan ikväll!

.

.
Sogeti Sverige Alumni

Läs mer om Alumnikvällen:
http://www.sogeti.se/Nyheter-Media/Kalendarium/Alumnikvall-pa-Sogeti-2011/

Gå med i vår alumnigrupp
Sogeti Sverige Alumni på LinkedIn:
http://www.linkedin.com/groups?mostPopular=&gid=2591690

.

Annons
h1

Japan ♥ Lean & Agile?

torsdag, 27 maj, 2010

För några dagar sedan kom jag och min flickvän hem från en nästan två veckor lång visit till Japan.  Även om det var semester (och en riktigt bra sådan) kunde jag inte låta bli att reflektera över hur Lean och Agile passar ihop med den japanska kulturen och mentaliteten.

Fram tills nyligen trodde jag Leans hemland också kryllade av it-projekt som framgångsrikt kör Scrum eller andra agila utvecklingsmetoder. Men icke. Nyligen lärde jag mig att till och med Toytoa kör vattenfall på sin utvecklingsavdelning och efter att lärt känna Japan close-up så förstår jag att även om Lean fungerar perfekt i den japanska kulturen och mentaliteten så innehåller det agila manifestet och de agila principerna värderingar och utmaningar som för en japan kan ses som obegripliga, paradoxala eller till och med kanske förolämpande.

.

Ett välkänd japans ordspråk lyder ”Protect the Rules!”. Fundera över det en liten stund. Detta går helt stick i stäv med det agila manifestets ”Individuals and Interaction over Process and Tools”.

Individualism och självfötroende är skällsord. De äldre och dina ledarna är visare och utövar vist sin klokhet och makt. Ta inga initiativ själv utan att vänta på att ledaren i detalj beskriver uppgiften. Knappast en bra gryta för att koka ihop ett tight och kreativt team som upplever ”empowerment” och ”collective ownership”.

Vidare – precis som i Sverige, fast ännu mera, älskar man skyltar, områdeskartor, varningar och hänvisningar. Skulle du inte förstå skyltningen i tunnelbanan, gå vilse och sedan gå till kundtjänst och muttra på att det är svårt att hitta så kommer du självklart få fantastiskt artig och hövlig hjälp (på knacklig engelska). Vad du däremot inte får veta är huruvida personen som designade skyltningen och hänvisningarna kanske säger upp sig själv i skam över att han misslyckats att hjälpa dig hitta rätt. Detta sätt att se på ansvar och misslyckanden är inte något som uppmanar till kreativitet, mod eller viljan att ta initiativ.

Lean å andra sidan passar som fisken i handsken. Om man naivt och fördomsfullt tillåter sig förenkla kan man beskriva vissa aspekter av det japanska samhället som en effektiv och organiserad myrstack. Ingen är viktigare än någon annan och allt man gör är för kollektivets bästa. I fabriken ”myrstacken” är Lean (Toyota Production System) ett fantastiskt verktyg för effektivisering och förbättring, ett redskap som metodiskt och empiriskt analyserar och sedan formar om processen. Man behöver inte vara kreativ, blotta sina subjektiv åsikter eller ta initiativ för att applicera Lean, bara kunskap och analytisk förmåga krävs.

Japan har 0% arbetslöshet. ”Optimize the whole!”. Alla tar sitt jobb på största allvar och känner stor stolthet. Man jobbar långa dagar. Men vad man gör under timmarna på kontoret eller, om ett arbete går att göra mera effektivt, är nödvändigtvis inte alls lika intressant.

.

I Sverige har vi inga problem att klumpa ihop Agile och Lean. Vi ser massor med paralleller och likheter och för oss faller det sig naturligt att sträva efter båda värdegrunderna när vi formar vår utvecklingsprocess.

Utöver dessa reflektioner tog jag självklart med mig hem ett ton av andra intryck och upplevelser men dessa berättas någon annan gång, någon annan stans 🙂

.

PS. Jag ber om ursäkt i förväg om jag förargat någon med mitt naiva raljerande och smått fördomsfulla förenkling av det japanska samhället. Läs inlägget ovan med glimten i ögat och som en betraktelse som kanske berättar mer om mig själv än någon annan. DS.

h1

Scrum myt #4: Zoomar man in är Scrum bara små, små vattenfall

onsdag, 31 mars, 2010

”Om man zoomar in tillräckligt mycket i Scrum, in i en sprint så är det ju bara små, små vattenfall. Inget nytt under solen.” FEL!

.
.
.

Scrum är inte små, små vattenfall.

Det grundläggande arbetssättet:
1) planera,
2) utföra,
3) kontrollera och
4) agera

dvs. att man tänker och planerar innan man handlar är inte synonymt med vattenfall.  Så gör man i alla situationer, oavsett uppgift.

.

Så, till skillnad från vattenfall så…

  • Levererar Scrum affärsvärde och ROI väldigt tidigt.
  • Scrums korta feedback cykler förändrar dagligen planen och planering.
  • Planering i Scrum fokuserar på att leverera affärsvärde (inte sprida ut arbetsuppgifter och deadlines i en kalender).
  • Scrum processen är själv-justerande och själv-förbättrande genom kontinuerlig utvärdering och granskning (i motsats till att ha en projektutvärdering i slutet).
  • Scrum välkomnar förändringar, till och med sent i processen, och detta är en naturlig del av processen.
  • Springer man in i bekymmer och tidsnöd så anpassar man i Scrum omfattningen (i motsats till att låta arbetsuppgifterna i planen skjutas framåt som ett tåg av dominobrickor).
  • I Scrum räknas inte framgång i antalet implementerade krav per deadline utan i levererat affärsvärde och kundnytta per sprint.
  • Levereras projektet enligt Scrum kan beställaren efter valfri* Sprint säga ”Nu är jag nöjd” (till skillnad från vattenfallsapproachen då allt eller inget levereras).
  • Scrum levererar potentiellt installerbar system/levererbar produkt varje sprint. Dvs. dokumentation, test, förvaltningsöverlämning etc. ska ske kontinuerligt (i stället för att komma som faser i slutet).

* Brasklapp. Det kan såklart dröja några sprintar innan man nått en minimal nivå av funktioner för att produkten ska gå att använda över huvud taget. Och ibland kanske det också krävs en stabiliserings- och Deploy sprint efter att beställaren ”är nöjd”.

.

Jag kan fortsätta rada upp skillnader. Jag hoppas dock i och med detta utbrott att det en gång för alla är vederlagt och fastslaget att det är stor skillnad mellan sekvensiell up-front planering/big-bang leverans (a la vattenfall) och agil planering/iterativ inkrementell leverans (Scrum). Fast att tro något sådant kanske vore nog naivt…

h1

Scrum myt #1: Agilt betyder ”Ad hoc”

fredag, 5 mars, 2010

Överhörde häromdagen ”Jag angriper det här väldigt agilt, det vill säga jag tar det som det kommer”.

Suck.

Om personen ifråga menade ”Jag planerar inte mitt hobbyprojekt utan gör vad jag känner för från dag till dag” är det ändå verkligen långt ifrån Just-In-Time and Just-Enough planering, ett angreppssätt som tillämpas i Scrum. Att jobba ”Ad Hoc” är inte att jobba agilt.

Det vore som att säga att man är kristen bara för att man håller med om att ett slumpvis valt budorden verkar vettigt att följa, t.ex. ”Du skall icke dräpa”.