Soft as in "Software" - part II (The Fear of Change)

In my last post I described my epiphany about the way the business looks at IT (or at least one very possible look) and left off just before I described the common reasons for delivering crappy software. So here they come:

• Fear of change
• Rigid structure

First, and probably foremost, is the fear of change. The uncomfortable feeling every one of us has felt at one point or another (probably more likely at a lot of points, but may be that's just me ;) ) in his career when he has to change something in code that has been in production. Will it work with all the other components that are deployed? What about the bug that we fixed last month, does it affect the fix in any way? What will happen if it does not work, can I go back to the old version of the code?

These are all questions which we are often quite uncertain about how to answer. How can we eliminate this discomfort?

By building quality in our products and continuously inspecting them for that quality - with unit testing, integration testing, and acceptance testing.

Having nailed down the behavior of your software this way gives you a lot of confidence and eagerness to continue improving and developing your software. Do the green bars mean that you are 100% safe? Definitely not, but now you have a base which will free your mind from trying to remember all the little things you need to make sure your software works as you expect. If you take the time to keep this base growing as your code grows it will allow you to go quite far. The alternative I have seen is where you reach a point where you cannot go any further and remain sane, and then it is time to start over (or the "big refactoring" comes ... ). Time for the bullies to go asking for investment in rewriting.

Next, the Zen of software development ...

15.12.2008 | Comments [1]
Flokkur: Agile | Forritun
Höfundur: Petar Shomov

Ferlisskoðanir (e. retrospectives) og markmið #1

Undanfarið þegar ég hef verið að þjálfa teymi í að nota ferlisskoðanir til að bæta vinnuferli sitt hef ég meira og meira verið að hjálpa þeim að setja niður hugmyndir sínar á forminu:

• Langtíma markmið
• Skammtíma aðgerð (sem færir teymið nær langtíma markmiðinu)

Ástæðan fyrir því var sú að út úr ferlisskoðunum teyma komu ágætis umbótaaðgerðir en þar sem þær áttu einungis að taka einn sprett (yfirleitt 2 vikur) voru þær oftast annað hvort dálítið metnaðarlitlar eða of víðtækar.

Tökum dæmi um of víðtæka aðgerð:

"Förum að skrifa sjálfvirk einingapróf áður en við skrifum kóða (TDD)".

Þar sem þessi aðgerð gerir ráð fyrir að allir í teyminu fari af stað með TDD í einu nær hún ekki settu marki vegna þess að fólki fallast hendur. Of víðtækar aðgerðir eins og þessi eru ekki framkvæmdar og það var það sem var að gerast hjá sumum teymanna. Í staðinn var eitthvað annað gert sem tók stuttan tíma en hafði ekki eins mikil langtíma jákvæð áhrif á vinnuferlið. Hugmyndina fékk ég að láni frá Bas Vodde.

Þegar þetta par langtíma markmið/skammtíma aðgerð er notað getum við farið að búta mikilvægar betrumbætur niður í viðráðanlegar aðgerðir. Ef við höldum áfram með dæmið að ofan þá lítur sú aðgerð meira út eins og langtíma markmið:

• Markmið: Skrifum sjálfvirk einingapróf áður en við skrifum kóða (TDD)
• Aðgerð: Nonni ætlar að TDD-a 1 klasa í næsta spretti

Þetta er augljóslega mun viðráðanlegra heldur en að keyra alla af stað með TDD.

Þetta vekur hins vegar upp spurningar um hvort það sé markmið út af fyrir sig að nota TDD!?! Höfuðmarkmiðið er náttúrulega það að gera teymið betra og betra við það sem það er að fást. Það hvernig höfuðmarkmiðið og markmiðið í dæminu okkar tengist langar mig að fara betur yfir í annarri færslu. Framhald síðar...

08.12.2008 | Comments [3]
Flokkur: Ferlisskoðanir
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

Soft as in "Software"

Recently my company organized a nice conference about software agility and building an agile company. Among the speakers were Jeff Sutherland and Dean Leffingwell - two names that are very well known in the agile community. We had dinner with Dean on one of those days and were looking at the software industry from high and above (do not remember the context really but that is not that important for my point) and then Dean made a remark that made me think for a while. He noted that software rots a lot and that's the reason we (software people in general) keep getting hired, so we would write the software (again) using the new cool platforms and APIs of the day.

As good as this may sound for software people I wonder what kind of perception business people investing in IT have of us. Do they feel uneasy every time they hear about the need to invest in re-writing the information system they have just started using the last year because you see the database has to be upgraded since the vendor is putting an end to that product, and now has a new more expensive product with more features. These businessmen probably wonder what happened to the "soft" in "software". And they get crushed with acronyms if they try to say "but  ... do we need that?' - SOA, REST, AJAX, WEB 2.0, WSDL, WPF, WWF, WCF, etc. You get the picture.

Imagining these things I figured these people that are the real customers of our industry are probably not real happy. Probably feel more like bullied into it then really buying into it. I mean they need IT there is no way around that, we have put them in one big vendor lock, haven't we ;)

So what is stopping software people from really making the customers happy? What would it take to make software that is long-lasting and easy to adapt to new platforms and APIs?

To be continued ...

04.11.2008 | Comments [5]
Flokkur: Agile | Breytingar
Höfundur: Petar Shomov

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

Áhugaverð blogg úr Agile heimum #3

Það sem vakti helst athygli mína í Agile bloggheimum síðan síðast:

• Project Automation eftir Naresh Jain - Naresh um hvað hann telur þurfa að sjálfvirknivæða í hugbúnaðarverkefnum
• Agile RFP sería eftir Peter Stevens - Peter er búinn að skrifa fyrstu tvo partana af þessari seríu og eru þeir báðir mjög áhugaverðir - sérstaklega fyrir þá sem eru annað hvort að bjóða hugbúnaðarverkefni út eða taka þátt í útboðum
• Kanban Systems eftir James Shore - Einstaklega skýr og upplýsandi grein um hvað Kanban, hvernig teymi eru að nota það og hvað Jim líkar við þess konar vinnulag. Mæli líka með kommentunum frá lesendum.
• The new user story backlog is a map eftir Jeff Patton - Hef nú bloggað um "story mapping" hugmynd Jeffs áður og í þessari grein fer hann vel í gegnum hana
• Jeff Sutherland's Sprint Emergency Landing Procedure eftir Dean Leffingwell - Dean að fjalla um nokkuð sem Jeff Sutherland fór í gegnum á Agilis 2008 - varð bara að minnast á þetta þar sem Ísland og Sprettur koma fyrir í blogginu ;)

26.10.2008 | Comments [3]
Flokkur: Agile
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