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

Batman hlutverkið

Þ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!

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.

Þ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

Þ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?

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

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

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é.

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."

• Þ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!