Batman

"Já, Scrum lítur vel út, en hvernig eigum við að höndla allar litlu beiðnirnar um hjálp, alla eldana sem við þurfum að slökkva, í þessum sprettum?"

Þetta er ein þeirra spurninga sem oftar en ekki koma upp þegar við erum að byrja að koma teymum af stað með Scrum. Hún á líka fyllilega rétt á sér. Staðreyndin er sú að aðstæður margra teyma eru þannig að það VERÐUR að vera hægt að takast á við það sem ekki er hægt að áætla í upphafi spretts. Mörg teymi sem fara af stað með Agile aðferð, eins og Scrum, lenda nefnilega í því að allar truflanirnar vegna villna í raunumhverfi sem "þarf" að laga NÚNA, símtala frá notendum (innanhúss eða utan) sem vilja breytingar/lagfæringar, o.s.frv., gerir þeim ómögulegt að skuldbinda sig svona og standa við það.

Það eru nokkrar leiðir færar í þessu máli. Þegar ég segir færar á ég við leiðir sem hafa það að markmiði að gera teymi kleift að skuldbinda sig í upphafi spretts til þess að ná settu markmiði og notandasögum því fylgjandi og standa við það. Þær sem ég lýsi iðulega fyrir teymum sem spyrja þessarar spurningar eru

1. Sérstakt slökkviliðs-teymi
2. Batman hlutverkið
3. Nægur slaki í spretti til að leysa óvænt mál (á við stabílli umhverfum).

Ég ætla þó bara að fara í 'Batman' hlutverkið í þessari færslu. Þess ber að geta að ég tók þessa hugmynd úr hinni stórgóðu bók Jim Shore, The Art of Agile Development.

Batman hlutverkið

Í stuttu máli snýst þetta um að teymi ákveður að einn meðlimur þess hafi á sinni könnu að takast á við að slökkva eldana ("batman saves the day!"). Með því veitir Batman hinum í teyminu frelsi til að einblína á það sem áætlað var að gera í upphafi spretts.

Þessu er venjulega stillt þannig upp að teymismeðlimir skiptast á að gegna þessu hlutverki innan hvers spretts. Sum teymi skipta á hverjum degi, önnur nota 2 dagar/3 dagar reglu og enn önnur skipta á vikufresti. Það skiptir í sjálfu sér ekki máli svo lengi sem við reynum að nota reglu sem hentar teyminu og hjálpar því að halda fókus og standa við sínar skuldbindingar.

Batman-inn í teymum sem ég hef unnið með nær yfirleitt að leysa a.m.k. 60-70% af "eldunum" án þess að trufla aðra í teyminu. Eftir því sem þekkingin í teyminu dreifist betur, því hærri verður þessi prósenta.

Hvað segið þið? Eru einhver teymi þarna úti sem nota Batman hlutverkið? Endilega kommentiði á þessa færslu um ykkar reynslu!

01.02.2009 | Comments [0]
Flokkur: Agile | Stjórnun
Höfundur: Daði Ingólfsson

The Decline and Fall of Agile

James Shore posted an excellent blog entry titled The Decline and Fall of Agile about what he's seeing happening with many Scrum teams, provoking a myriad of responses all over the agile blogosphere.

A few of the posts:

Robert C. Martin (Uncle Bob)

InfoQ

Jeremy Miller:

In my opinion, Scrum is a kind scaffolding around the team where value is actually created, used to construct the real process, one improvement at at time. And, if you know where you can go, those improvements should lead more or less towards XP engineering practices. The reality is that Scrum is a lot easier to sell than XP in its entirety, especially when it comes to getting people to rally around a process change to begin with. XP, on the other hand, with its 12 practices, can be mind boggling to start with if you don't have a coach who really knows the drills.

People, knowing only Scrum without the technical practices to make shorter cycles work in the long run, are going to get into trouble. It's as simple as that. Of course not everybody is going to be equally good at it, but awareness is a key element. If not believing something is possible makes sure it won't happen then not knowing about a possibility is an even better way to ensure it never happens. So introducing Scrum as a complete package into a company without at least ensuring awareness of the technical practices, is a risky practice IMHO.

We are fully aware of these risks here at Sprettur, and are ready to provide training in the engineering practices talked about in these posts. Contact us for details.

17.11.2008 | Comments [5]
Flokkur: Agile | Scrum | Sprettur | Stjórnun | Tækni | XP
Höfundur: Guðlaugur Stefán Egilsson

Jason Fried á Business of Software ráðstefnu

Horfði nýlega á þennan skemmtilega fyrirlestur Jason Frieds sem er einn eigenda eins af uppáhalds fyrirtækjunum mínum, 37signals.

Fyrirlesturinn hans er strúktúreraður þannig að Jason eyðir fyrri hálftímanum í að úttala sig um nokkra punkta sem honum þykja mikilvægir. Seinni hálftíminn er svo Q&A. Mæli sérstaklega með fyrri hlutanum og langar að nefna nokkra af punktunum hans og spá aðeins í þeim.

• Skriðþungi (e. momentum). Jason segir að hjá 37signals sé öllu sem þeir þróa skipt upp í lítil verkefni sem hægt er að klára á stuttum tíma svo hægt sé að nýta skriðþunga stemmningar, spennings og vilja fólks til að klára verkefni. Fyrir mér var þetta enn einn plúsinn í kladdann fyrir ítrunarþróun Agile aðferða. Fólk finnur fyrir þessum skriðþunga, afkastar meira og klárar það til enda - sem er gott ;)
• Út með kröfulýsingar. Það kemur þeim sem eitthvað þekkja til Spretts lítið á óvart að hér erum við algjörlega sammála Jason. Það sem ég hafði ekki heyrt áður er hvernig Jason lýsir þess konar skjölum sem já-skjölum! Það sem hann á við er að skjölum eins og kröfulýsingum er svo auðbreytt: "Já, góð hugmynd að fítus. Bætum við setningu fyrir hann í skjalið". Að bæta fítus við í skjal tekur mun minni tíma en nokkurn tíma að útfæra fítusinn í alvöru vöru! Þess vegna er svo auðvelt að segja alltaf já við hvaða hugmynd sem er þegar ekki þarf að hugsa alla leið.
• Truflanir drepa framleiðni. Já, en þar sem ég átti bágt var þegar Jason lýsti því yfir að því minna augliti-til-augliti samneyti sem teymi hafa, því meira kæmu þau í verk! Ok, ég tel mig skilja rök hans, sem eru að skv. þeirra reynslu fer framleiðni þeirra niður þegar þeir eru of mikið á sama stað vegna þess að þeir eru sífellt að trufla hvern annan. Ég er sammála Jason að þetta sé staðreynd þegar meðlimir teymisins eru að vinna að mismunandi verkefnum, hafa allir sitt sérsvið sem enginn annar fer inn á, vinna aldrei í pörum og þurfa ekki mikla hjálp hvers annars. Mín skoðun er hins vegar sú að samhent, sjálfstýrandi teymi fólks sem vinnur að sama markmiði, í pörum (þegar við á), á sama stað og getur gengið í verk hvers annars geti orðið margfalt framleiðnara heldur en hópur einstaklinga.
• Fókuseraðu á það sem ekki breytist. Ef við fókuserum á að gera alltaf nýjasta nýtt með vörurnar okkar missum við að miklum tækifærum til þess að gera það sem skiptir mestu máli til langframa fyrir þær. Það sem skiptir máli í vörunum okkar er það sem gerir það í dag og eftir 10 ár! Skoðiði ykkar bissness og finniði út hvað það er sem fólk mun alltaf vilja frá ykkur og fjárfestið í því, ekki bara endalausum nýjungum.

Þetta eru aðeins 4 af punktunum hans Jasons og ég ætla ekki að spá í fleirum hér en hvet ykkur aftur til að kíkja á þennan fyrirlestur.

03.11.2008 | Comments [3]
Flokkur: Stjórnun
Höfundur: Daði Ingólfsson

Að koma hlutum í verk

Verandi með nokkra hatta á höfðinu þessa dagana, svo sem "eiginmaður" og faðir, húseigandi, kennari við HR, fjármálastjóri Spretts, verktaki hjá Símanum og wanna-be hlaupari, og með nokkuð mikið að gera, þá var ég kominn í stöðu sem kallast "thrashing" á tölvumáli. Thrashing er það ástand sem örgjörvar lenda í þegar nýting þeirra nálgast 100% í fjölvinnsluumhverfi, þ.e. að  undir vissum kringumstæðum þá fer meiri tími/orka í að skipta um verk heldur en í að vinna þau.

Hausinn á mér rúmaði ekki lengur neitt nema hluti sem ég þurfti að gera, og verulega stór hluti af minni orku og athygli fór í að skipta um verk, og of lítill í að hugsa um hvernig væri best að gera þau. Ekki lengur.

Ég "las" núna nýlega bók með því ágæta nafni "Getting Things Done" eftir David Allen, þ.e. ég hlustaði á hana sem hljóðbók, og ég verð að segja að þetta er einhver praktískasta bók sem ég hef lesið í seinni tíð.

Nokkrar öflugar hugmyndir úr bókinni:

 - Það að skrifa ekki niður það sem menn hafa í huga að koma í verk er eins og að halda öllu í RAM á tölvu. RAM er ekki hentugt sem geymslumiðill til lengri tíma. Vel skipulagt "todo" kerfi er eins og harður diskur sem losar vinnsluminni til að vinna að mikilvægari hlutum.
 - 2 mínútna reglan: Ef þú telur að taki minna en 2 mínutur að bregðast við áreiti (tölvupósti, hugmynd sem þú fékkst, bréf inn um bréfalúguna), þá skal gera það strax. Annars má íhuga að fresta því. 2 mínútur er u.þ.b. þröskuldurinn þar sem fer að verða dýrara að halda utan um verkið en að framkvæma það strax.
 - Skipuleggja innbox alls staðar þar sem áreiti á sér stað, minnisbók á ferðinni, á skrifstofunni og á tölvunni, og hafa nákvæmlega eitt skipulagt kerfi þar sem maður flokkar inn atriði til að gera úr ÖLLUM innboxum.

Ég er kominn af stað að útfæra þetta kerfi, og finn greinilegan mun nú þegar á öllu vinnulagi hjá mér. Ég mæli því eindregið með þessari bók við alla þá sem hafa áhuga á að koma hlutum í verk. Til að auka skilvirkni í því sem menn eru að gera þá er þetta stórgóð bók.

Það er samt gott að hafa í huga að aukin skilvirkni (efficiency) er ekki endilega ávísun á meiri/betri áhrif (effectiveness)...

07.10.2008 | Comments [4]
Flokkur: Bækur | Sprettur | Stjórnun
Höfundur: Guðlaugur Stefán Egilsson

Áhugaverð blogg úr Agile heimum

Það sem vakti helst athygli mína í Agile bloggheimum þessa vikuna:

• Observed Requirement frá Martin Fowler - Martin nefnir nokkrar nýstárlegar leiðir sem sumir nota í dag til að uppgötva hvað notendur vilja eða þurfa
• Tactical vs Strategic misses the point - Jason Yip talar um sínar skoðanir á hönnun sem hugsar út fyrir einstök verkefni og hönnun sem hugsar einungis um einföldustu lausn núverandi vandamáls
• It's not my fault, it's the vendor's fault - Jason skrifaði líka kjarnyrta færslu um samninga þar sem verð, tími og umfang eru meitluð í stein og hvar raunveruleg áhættan í þeim liggur
• The Equipoise of Agile - Israel Gat skrifaði þessa mögnuðu færslu um jafnvægislistina að hjálpa fyrirtæki að umbreyta sjálfu sér til að vinna eftir nýjum aðferðum og hugsa innan nýrrar hugmyndafræði

21.09.2008 | Comments [0]
Flokkur: Breytingar | Stjórnun
Höfundur: Daði Ingólfsson

Hverju eigum við að brenna?

Þau teymi sem vinna sína vinnu í sprettum/ítrunum þekkja flest svokölluð brennslurit, ekki satt?!?! Jæja, kannski ekki íslenska heitið en það sem á ensku kallast burndown chart. Þegar teymi vinna í sprettum inniheldur sprettsbackloggurinn (e. sprint backlog) sögur sem oftast eru í stærðarmældar í sögupunktum og tæknileg verk (e. technical task) sem mæld eru í ótrufluðum klukkutímum. Vaninn er að fylgjast með því hversu vel teyminu vindur fram innan spretts með því að plotta á línuriti tímana sem eftir eru miðað við dagafjölda spretts. Dæmi má sjá hér að neðan um brennslurit spretts.

Eins og sést þá má nota svona rit til að sjá, gróflega, hvort það sem teymið skuldbatt sig til að gera á áætlunarfundi sprettsins muni klárast fyrir lok sprettsins. Þessi rit eru lýsandi, auðveld í uppsetningu og viðhaldi, og segja okkur oft meira heldur en verkveggurinn okkar (e. task board). Gallinn við brennslurit sem sýna brennda klukkutíma er að þau segja okkur ekkert um hversu margar sögur teymið er búið að klára til enda. Það má náttúrulega segja að samvinna brennslurita og verkveggja ætti að nægja til að segja teyminu og hagsmunaaðilum hversu vel gengur að klára eitthvað sem verður hægt að skoða/prófa/nota í lok sprettsins. Þroskuð Agile/Scrum teymi færa sig þó oftar en ekki yfir í að mæla sögupunkta frekar en ótruflaða klukkutíma. Eitt teymi sem ég hef verið að vinna mikið með á þessu ári er að prófa sig áfram með að mæla bæði, eins og sjá má á eftirfarandi ljósmynd.

Eins og sést glöggt á þessu riti þá var teymið að klára tæknilegu verkin sín nokkuð jafnt og þétt en sögurnar sjálfar voru ekki að klárast fyrr en undir blálokin. Þetta eru mikilvægar upplýsingar sem geta sagt okkur ýmislegt um teymið og að skoða svona rit í ferlisskoðun (e. retrospective) getur hjálpað teyminu að ræða um hvernig það ætli sér að gera tilraunir til að bæta sögubrennslu sína í næsta spretti svo það sitji ekki eftir með mikið af tæknilegum verkum kláruðum en ekkert til að sýna á demói.

Hver er ykkar reynsla af brennsluritum sem þessum? Hafið þið endað uppi með fullt af tæknilegri vinnu unninni en ekkert til að sýna vörueigendunum á demóinu?

17.09.2008 | Comments [0]
Flokkur: Scrum | Stjórnun
Höfundur: Daði Ingólfsson

Tískubólur

Já, hann Ívar hefur ýmsa fjöruna sopið. (6:02 mín)

08.09.2008 | Comments [2]
Flokkur: Stjórnun | Tækni
Höfundur: Pétur Orri Sæmundsen

Teymið sem minnsta vinnueiningin

Ég hef lengi verið þeirrar skoðunar að teymið eigi að vera minnsta vinnueiningin í fyrirtækjum í þekkingariðnaði. Af svo mörgum ástæðum er það ólíklegt til árangurs að vera með einnar-manneskju-verkefni og Johanna Rothman minnti mig sérstaklega vel á það í nýjustu bloggfærslu sinni. Eins og Johanna bendir réttilega á þá er það hreinlega ómögulegt að búa til kerfi sem geymir alla vitneskju forritara um eitthvað kerfi. Þess vegna er eina almennilega færa leiðin að vera með þverfagleg teymi sem hafa fókus á einu verkefni í einu, klára það og fara í það næsta, og koll af kolli. Þetta stjórnskipulag hefur m.a. í för með sér að:

• Vitneskjan er nú í mörgum hausum sem minnkar áhættuna á að þekkingin um kerfið hverfi
• Fólk fær skýr skilaboð um hvað skipti máli og getur einbeitt sér að einu í einu
• Stjórnendur geta ekki lengur hent hvaða verkefni sem er í gang þar sem teymi verður að vera til staðar til að vinna það
• Verkefni klárast! Í stað þess að dragnast með of mörg verkefni allt árið og reyna að "loka" þeim í árslok þá klárum við verkefnin eitt í einu
• Fólk vinnur og líður betur í teymum heldur en eitt út í horni (flestu alla vega...)

Eins og Johanna bendir á í þessu sambandi er að nú þarf fókus stjórnenda að færast frá því að hafa áhyggjur af því hversu fullnýttur tími starfsmanna er yfir í það að hafa áhyggjur af því hversu mörg virðisaukandi verkefni hvert teymi klárar. Þá förum við að hafa meiri tíma í hugsa um það hvað er virðisaukandi, hvað er það sem skiptir máli að teymin okkar vinni í. Það er í raun mun mikilvægara en nokkurn tímann hversu mikið er að gera hjá hverjum og einum í fyrirtækinu.

01.09.2008 | Comments [2]
Flokkur: Stjórnun
Höfundur: Daði Ingólfsson

Dagur 3 á Agile 2008

User Story Mapping með Jeff Patton

Ég var búinn að ákveða fyrir ansi löngu að mæta á þetta námskeið - alveg frá því Jeff kom upphaflega með tillöguna að því í febrúar síðastliðinn (valferlið á námskeiðum ráðstefnunnar var opið öllum í fyrsta sinn í ár).

Aðferðin sem námskeiðið gekk út á er ansi áhugaverð. Tilgangur hennar er að hjálpa Agile teymum að skilja markmið og þarfir notenda sinna, og að sjá skóginn fyrir trjánum þegar að notandasögum kemur. Jeff byggir þessa aðferð á "Goal-Task-Tool" módeli Don Norman. Hann aðlagar það módel fyrir hugbúnað eins og þessi mynd sýnir:

Út frá þessu módeli sjáum við að notandasögurnar okkar geta verið skrifaðar út frá "task" eða "tool" (Jeff notar reyndar orðið "feature" fyrir "tool" í hugbúnaðarþróun og á myndinni). Dæmi um "task" sögu væri

Sem áhugagarðyrkjummanneskja
vil ég grafa holu
svo ég geti plantað tré.

en "tool" saga væri

Sem áhugagarðyrkjummanneskja
vil ég fá skóflu
svo ég geti grafið holu.

Með þessu sýnir Jeff muninn á sögunum eftir því hvort við erum að horfa á hærra stigs markmið notandans eða lausnina sem við teljum að muni hjálpa honum að ná markmiðum sínum.

Jeff sýndi okkur hvernig hann notar "Goal-Task-Tool" módelið til þess að kortleggja kerfi með því að setja upp "web cam" sem hann beindi niður á borðið sitt, sýna myndina á skjátjaldinu og kortleggja kerfi sem einn sjálfboðaliði á námskeiðinu er að vinna með í sínu fyrirtæki. Þetta tók hann minna en 10 mínútur og var hann þá kominn með "kort" af helstu markmiðum notenda, hvaða verknað (e. activity) þeir þurftu til að ná markmiðum sínum og hvaða röð aðgerða/fítusa (e. tasks/tools) þeir þurftu að beita við verknaðinn. Greinilega ákaflega gott að greina kerfi með þessu módeli og mismunandi lituðum spjaldskrárkortum. Það sem Jeff gerir svo þegar hann er kominn með kjarnaaðgerðirnar er að brjóta þær meira og meira niður til að sjá hvernig hægt er að útfæra aðgerðirnar ítarlegar og ítarlegar.

Jeff talaði um ýmislegt fleira áhugavert, eins og að búa til "span plan", en það væri of langt mál að fara út í hér þannig að ég bendi áhugasömum á að fara í gegnum glærurnar hans.

From Concept to Backlog með Gerard Meszaros

Gerard hóf þennan fyrirlestur á því að ræða spennuna milli BDUF (Big Design Up Front) og LRM (Last Responsible Moment) innan Agile hreyfingarinnar. Það eru algeng byrjendamistök að halda að engin áætlanagerð, greining eða hönnun fari fram við upphaf verkefnis sem keyrt skal með Agile aðferðum. Gerard skiptir upphafinu í tvennt: þróun vörusýnar og áætlanagerð vöru. Hann fór svo yfir það sem hann gerir vanalega innan þessara tveggja skrefa með sínum teymum. Ætla nú ekki að lýsa öllu sem hann talaði um þar sem þið getið skoðað það sjálf hérna.

Það sem vakti helst athygli mína á fyrirlestrinum var það sem hann kallaði "Wizard of Oz Testing". Þessi aðferð hjálpar teymum að finna galla á flæði og hönnun notendaviðmóts helstu aðgerða verðandi kerfis á mjög ódýran hátt. Með því að eyða 2-3 dögum í að búa til einfalda pappírsfrumgerð af helstu skjáum kerfa hefur Gerard fundið margar grundvallarhugsanavillur í viðmótshönnun þeirra. Það gerir hann með því að taka þessa pappírsfrumgerð og fá til liðs við sig nokkra alvöru notendur sem prófa að nota frumgerðina í klukkutíma eða svo. Hann leikur svo tölvuna og skiptir út pappírsskjám eins og við á út frá skipunum þessara notenda. Einn til tveir aðrir samstarfsfélagar hans fylgjast með og skrá athugasemdir niður á blað. Með þessum einfalda hætti sannreynir hann fyrstu hugmyndir sínar um hegðun kerfisins strax í upphafi.

What Are They Doing? What A CIO Wants To Know From An Agile Development Team með Niel Nickolaisen

Hann er skemmtilegur fyrirlesari þessi Niel en mér fannst fyrirlesturinn hans nú kannski fjalla meira um hvernig er að vera CIO (Chief Information Officer), hvernig þeir hugsa og hvernig hann hefur kynnt Agile inn í sitt fyrirtæki frekar en hvað CIO vill fá frá Agile teymum. Alla vega, aðal skilaboðin frá honum voru að ef þú vilt nota Agile til að ná árangri þá skaltu tala um hvernig þú ætlar að skila viðskiptalegum árangri án þess að blanda Agile/Scrum/XP/... í málið. Talaðu um Agile grundvallarreglurnar, gildin og aðferðirnar þannig að fólkið sem þú þarft að hafa áhrif á finnist þú vera að tala um kunnuglega hluti. Það er ekki eins erfitt og það gæti sýnst þar sem Agile byggir á gömlum grunni sem útfærður er á nýstárlegan máta. Niel treystir á að það sem okkur finnst kunnuglegt, hræðumst við ekki og vitnar í Cockburn í þessu sambandi:

"We prefer the familiar to the comfortable and the comfortable to the better."

Niel tók undir með fleirum innan Agile hreyfingarinnar þegar hann sagði "ROI is an illusion"! Hann taldi upp nokkra punkta sem lýstu afstöðu hans til árangursmælinga. Hann sagði mælingar

• Þurfa að styðja við stefnu fyrirtækisins
• Eiga að vera fáar og auðskildar>
• Eiga að vera að mestu leyti ófjárhagslegar
• Eiga að notast til að betrumbæta ferla, ekki til að kenna fólki um!

24.08.2008 | Comments [3]
Flokkur: Agile 2008 | Stjórnun
Höfundur: Daði Ingólfsson

Agile 2008 - The Wisdom of Crowds

Opnunarræða Agile 2008 var haldin af James Surowiki, höfundi "The Wisdom of Crowds". Eins og titillinn gefur til kynna, þá fjallaði hún um visku hópa, og getu þeirra til að leysa verkefni betur en færustu sérfræðingar í mörgum tilfellum. Hann fjallaði nokkuð um hvaða samsetning af hópum væri til þess fallin að taka góðar ákvarðanir, og hvers konar umhverfi þyrfti að vera til staðar til að styðja við slíka ferla.

Einna áhugaverðast fannst mér er að fyrirtæki eru farin að beita þessu til að leysa vandamál, og ein aðferð sem hann nefndi til þess voru svokallaðir "spámarkaðir", eða "prediction markets". Í þessu tilfelli er verið að nýta þá staðreynd að bestu formlegu aðferðir til að gera spádóm um atburð í framtíðinni, eru ekki jafn góðar og meðaltal ágiskana tiltölulega upplýsts hóps. Sem dæmi um notkun, er að spá fyrir um hvenær ákveðin vara í þróun verður tilbúin til sölu.

Einnig ræddi hann um gagnstætt fyrirbrigði, sem er þegar hópur af greindum einstaklingum geta tekið heimskulegri ákvörðun heldur en nokkur einn þeirra væri fær um sem einstaklingur. "Því meira sem þeir tala, því heimskari verða þeir". Sem dæmi um þetta talaði hann um innrásina í Svínaflóa, sem eftir á séð var heimskuleg ákvörðun í alla staði samkvæmt niðurstöðu opinberrar skoðunar á atburðarásinni sem hrinti því af stað. Undirliggjandi vandamál í þessu tilfelli er að allir aðilar sem koma að ákvörðunni eru búnir að ákveða fyrirfram hver niðurstaðan á að vera (það er, innrás skal gerð á Kúbu). Ráðið sem Surowiki gaf til að verjast þessu er að ef menn komast of fljótt að samkomulagi á fundi, þá eru menn að missa af einhverju mikilvægu, og ættu að fresta ákvörðun þar til einhver kemst að því hvað það er. Önnur leið til að orða þetta, er að til að taka góða ákvörðun, þá þarf að takast á um hlutina málefnalega. Þar getur komið að haldi að menn spili hlutverkið "lögfræðingur djöfsa" (devil's advocate) reglulega, svo lengi sem það er ekki alltaf sami aðilinn...

14.08.2008 | Comments [0]
Flokkur: Agile 2008 | Sprettur | Stjórnun
Höfundur: Guðlaugur Stefán Egilsson

Það er erfitt að kenna gömlum hundum

Í stórgóðri bók sinni Leading Change fjallar John Kotter um forsendur vel heppnaðra breytinga og setur fram 8 skrefa ferli til þess að styðja við umbreytingar fyrirtækja.

Grunnforsendur bókarinnar eru að heimurinn sé stöðugt að breytast og viðskiptaumhverfi 21. aldarinnar kalli á öðruvísi stjórnunaraðferðir heldur en hafi verið við lýði síðastliðin hundrað ár. Aðferðir þar sem stjórnendur einbeita sér að því búa til framtíðarsýn og stefnu en gefi starfsmönnum lausan tauminn í útfærslu. (Það er ótrúlegt hvað vélhyggjuhugmyndir iðnbyltingarinnar sitja fast í stjórnendum. Menn eins og Kotter eru búnir að tala fyrir nútímalegri stjórnunaraðferðum í yfir 20 ár, en færibandið situr pikkfast.)

Átta skrefa breytingaferlið (sjá mynd) hefst með því að útskýrð er nauðsyn breytinganna. Það er andvaraleysið sem er helsti óvinur breytinga. Ef hægt er að ýta fólki út úr andvaraleysi og sannfæra það um mikilvægi breytinganna er farið í að setja saman teymi af leiðtogum sem í eru einstaklingar sem hafa völd, þekkingu, trúverðugleika og leiðtogahæfileika. Þegar rétta teymið er komið saman getur það þróað framtíðarsýn og stefnu. Góð framtíðarsýn lýsir því hvernig framtíðin lítur út og skírskotar til langtímahagsmuna starfsmanna, viðskiptavina og eigenda; sýnin er enn fremur möguleg, fókuseruð, sveigjanleg og einfalt er að lýsa henni og miðla. Oftast vanmeta leiðtogar í breytingaham mikilvægi þess að vera stöðugt að miðla framtíðarsýn breytinganna en ef sýninni er miðlað án tæknihugtaka og hægt er að setja hana fram í einhvers konar myndmál við hvert tækifæri, verður hún ákveðnari og áþreifanlegri. Þegar komnar eru af stað virkar samræður við starfsmenn er nauðsynlegt að fela þeim vald til að framkvæma sína þætti í breytingunum. Þegar starfsmenn eru byrjaðir í framkvæmdinni eru kallaðir fram sigrar í litlum áföngum en það er ekkert sem býr til meiri trúverðugleika á breytingarnar heldur en litlir sigrar. Nógu mikið af litlum sigrum slær síðan á raddir vantrúaðra og hægt er að sameina ágóða breytinga til þess að kalla fram meiri breytingar en þannig fá breytingarnar smátt og smátt kraft til þess ná yfirtökum á flóknu gangverki stærri fyrirtækja. Til þess að breytingarnar festist raunverulega í sessi þarf að festa nýjar aðferðir og nálganir í fyrirtækjakúltúrinn. Kúltúrbreytingar koma síðast þegar orðið er alveg ljóst að nýju aðferðirnar virka, en oft er fólk tregt til þess að samþykkja nýju aðferðirnar og í versta falli tekur fólk pokann sinn. Enn fremur gera kúltúrbreytingar fyrirtæki kleift að viðhalda breytingum þótt leiðtogarnir séu farnir.

Það er áhugavert að bera saman breytingaferli Kotters og Scrum en Scrum gæti verið útfærsla á ferlinu hans Kotters.

19.07.2008 | Comments [0]
Flokkur: Breytingar | Stjórnun
Höfundur: Pétur Orri Sæmundsen