Soft as in "Software" - Part III (Dependency Injection for the CEO)

In part I of this series I set the stage by introducing angry management/businessy types that feel like being ripped off with this IT stuff but out of peer pressure or what not they keep pouring money into software. In part II I looked at what I believed to be the top reason for the customer dissatisfaction: the fear of change. In this last part of the series I will look at a few of the techniques we at Sprettur believe to be the cure. For the sake of the complete picture I am going to say that we truly believe that the SOLID principles and the XP practices are the way to go, but trying to discuss all of them would make this line of posting very, very long.

So, let's say you are this guy with the solid base to lean on, what do you do next to stop your software from corroding? A few ideas: Dependency Injection, Separation Of Concerns, Domain-Driven Design. I will very quickly go over these and how they can help you, if you are interested just google for any of these and you will get a lot more info.

Dependency Injection allows your code to stick less. Non-sticking code has two benefits: 1) allows the good pieces of your code not to stick to the rotting ones; 2) when you try to take one piece of code and reuse it, it will not make you drag in a whole bunch of other pieces for it to work.

Wow, I guess I can call this explanation "Dependency Injection for the CEO" ;)

Next is Separation of Concerns. What that refers to is when you chop your software up in small pieces based on the granularity of the tasks they accomplish, and then combine the small pieces into bigger clusters to achieve new or bigger tasks. This way the rotting pieces will be separate from the good ones and it will be easy to replace them with "fresh" ones as needed.

There you have it - "Separation of Concerns for the CEO".

Now for the underdog, Domain-Driven Design. Domain-Driven Design (DDD) is not as hot as "agile" but it is gaining a lot in popularity lately. DDD has numerous benefits, but I am only going to look at how it can help your software deteriorate less. The core idea of this school of thought is that you should separate the core logic that makes your business run, from the infrastructure and APIs. I guess you can call it the ultimate anti-corroding technique, but that is the punch line of DDD - recognizing that the business logic far outlives IT infrastructure and therefore we should take extra special care of it, so it will keep delivering value long after cool and hip fades away.

I will try to summarize in a sentence or two. It seems to me that IT has not really proven to be delivering high value and I put blame for that on the Waterfall model and inadequate software quality. We have the knowledge and the tools to solve both problems so we should try to get them to the developers and managers out there. In practice that's what we do at Sprettur.

04.03.2009 | Comments [0]
Flokkur:
Höfundur: Petar Shomov

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

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