Orkustjórnun, hljóðbækur og brákuð rif

Það vildi svo til að ég lenti í því fyrir rúmum mánuði að bráka í mér rifbein. Félagi minn sem lenti í því sama ekki fyrir löngu síðan, hafði sagt mér að vika þrjú væri verst, fyrir utan fyrstu dagana, svona þegar þetta væri að skríða saman. Þetta gekk nokkuð vel eftir. Það gekk alveg þokkalega að sinna vinnu fram að því að rétt tæpum þrem vikum eftir brotið var ég farinn að vera verulega þreyttur, og kom að því að ég entist ekki nema hálfan daginn, og varð að fara heim, alveg búinn á því. Það vildi svo til að þennan dag byrjaði ég á því að hlusta á þessa bók.

Eitt af því sem þeir segja í þessari bók, sem er augljós sannleikur þegar maður heyrir hann, en greinilega eitthvað sem menn eiga auðvelt með að gleyma, er að við fáum orku okkar úr tveimur áttum. Matur og drykkur sem við borðum, og súrefni sem við öndum að okkur. Það er þetta síðara sem við tökum sem of sjálfsögðum hlut, og hugsum nánast aldrei út í. Þetta fékk mig til að hugleiða stöðuna sem ég var í, örþreyttur að fara heim um miðjan dag, þó lógískt séð ætti ég í raun að vera í betra standi heldur en vikuna á undan. Ég ákvað því að gera tilraun á mér, og gera öndunaræfingar eins og lýst er í þessari bók, það sem eftir var dags og næsta dag. Og árangurinn var mjög dramatískur. Ekki eingöngu entist ég til 7 daginn eftir á löngum og ströngum degi, heldur bar ekkert á þreytueinkennum eftir þetta.

Málið þarna er nokkuð augljóslega það að sársauki vegna rifbeinsbrots verður til þess að maður andar grynnra heldur en eðlilegt er, sem veldur síðan orkuleysi og þreytu. Um leið og maður gerir sér grein fyrir vandamálinu, og gerir einfaldar öndunaræfingar nokkrum sinnum á dag (anda djúpt að sér og hægt frá, endurtaka 2-3 sinnum á einni mínútu), þá hverfur vandamálið. Árangurinn við ofangreindar aðstæður er mjög dramatískur, og það gæti orðið mín heppni því ég mun aldrei gleyma þessu. Árangurinn fyrir fullfrískt fólk er umtalsverður líka, bara af því að anda meðvitað.

Fyrir utan þetta hef ég reynt að fara eftir öðrum ráðleggingum í þessari bók varðandi mataræði, öndun, líkamlega og andlega þjálfun og hvíld, og ég held að ég leyfi mér að segja að orkustigið hjá mér og vilji og löngun til allra verka sé nú þegar (2 vikum síðar) orðinn hærri heldur hann hefur verið í mörg ár. Ég rek það að mestu leyti til lestur þessarar bókar, og hvet ég því alla sem ég hitti núna til að lesa þessa bók. Það er að vísu stutt síðan ég las hana, en árangurinn hingað til lofar það góðu, að ég býst fastlega við að þessa bók muni ég í framtíðinni álíta sem þá af þessum bókum hér að neðan, sem mest hafði áhrif á mig.

- Guðlaugur Egilsson

Til gamans er hérna topp 10 listinn minn af hljóðbókum sem ég hef hlustað á:

1. The Power of Full Engagement         Jim Loehr and Tony Schwartz  
2. How We Decide (Unabridged) Part 1     Jonah Lehrer
3. The 7 Habits of Highly Effective People (Unabridged), Part 1     Stephen R. Covey
4. The Future of Management (Unabridged)     Gary Hamel, Bill Breen
5. Outliers (Unabridged)     Malcolm Gladwell
6. Beyond the Goal (Unabridged)     Eliyahu M. Goldratt
7. Getting Things Done (Unabridged)     David Allen
8. How to Win Friends & Influence People (Unabridged)     Dale Carnegie
9. Tuned In (Unabridged)     Craig Stull, Phil Myers, David Meerman Scott
10. The 8th Habit (Unabridged), Part 1     Stephen R. Covey

Aðrar hljóðbækur sem ég hef hlustað á (óraðað):

• Rethink (Unabridged)     Ric Merrifield
• What Got You Here Won't Get You There (Unabridged), Part 1     Marshall Goldsmith and Mark Reiter
• Dumb Money (Unabridged)     Daniel Gross
• The Audacity of Hope     Barack Obama
• Crucial Conversations     Kerry Patterson, Joseph Grenny, Ron McMillan, and Al Switzler
• Lean Solutions     James P. Womack and Daniel T. Jones
• Made to Stick (Unabridged)     Chip Heath and Dan Heath
• The E-Myth Revisited (Unabridged)     Michael E. Gerber

17.10.2009 | Comments [0]
Flokkur:
Höfundur: Guðlaugur Stefán Egilsson

Lessons learnt the hard way

I just got off a large project that one of our customers is running. I will not go into details but it should suffice to say that it is a rather large multi-phase project that is supposed to create the future IT backbone for that customer. Before I move on I though I should stop and analyze what we did right, what went wrong and what can I learn from this experience. And I thought I would share it with you dear reader ;)

1. Deploy by the end of the first month to a user
In large companies there are usually many reasons why a project cannot be deployed: dependency on another project which in turn depends on another project and so on, or someone has to get legal approval for something to be released. Yes, there are many excuses not to deploy, but in the end that's all they are - excuses. The business needs to see value, your team needs to get feedback from real users about the system otherwise you are risking building something no one is interested in and/or the business people loosing their business patience. My future rule of thumb would be - if you have not deployed to actual users by the end of the first month of the project, you need to do get angry and demand this to happen right away.

2. Do not accumulate technical debt, push back on Product Owner who does not understand technical debt
Technical debt(from here on referred to as tech-debt) is hard to explain to product owners that have not programmed. This is understandable and there is no easy way around it. We tried all kinds of metaphors but I don't think we succeeded in communicating what tech-debt is and why it is important. The best approach that I can see working is to negotiate a slice of each sprint to go into paying off tech-debt and demand extra on top of that at the first sign of trouble. Letting it pile and telling yourself that it is ok, that you are going to fix it "later" does not work. Never has, not for me. "Later" the debt is usually so big and the bad stuff has usually spread all over the place and fixing it becomes an all-or-nothing mini-rewrites that are very hard to do and are rather unpleasant and unsatisfying experiences.

3. Do not allow architectural astronauts to tell you what tools to use
It is a strange phenomenon but seems quite persistent: a company becomes mid-sized and someone decides that now they need to unify "how we do things around here". And then an Architect (may be even Chief Architect) is appointed who starts googling and creating a list of tools and technologies allowed to be used. And this is the moment when you start to be told what tools to use to do your job by the guy who has never done your job or it has been a while since he has last done your job. Do not let this happen, say "no" to company politics and demand that you decide what tools to use. The list of tools should be coming from you and the rest of the guys that are working in your organization. Architects can be valuable, but this is not the way. Do not buy into tool vendors based on power point presentations and one day carefully orchestrated demos from the salesman. You and your peers should be making the standard in your company. 'nough said.

4. Manage expectations so that they are achievable
I have come to appreciate marketing as a *very* important aspect of product development. The same product may be perceived as two complete opposites depending on how its being marketed. One thing that I've found out is not wise, is to proclaim that your product will be a universal panacea that will fix all there is to fix. This might sound obvious and plain common sense, but I am mentioning it for a reason: the larger the promise you make, the more difficult is to keep it. So I would advise to do small achievable projects and build software products incrementally and iteratively. And the product owners have always to be on the lookout how to generate value with minimum effort.

Well, I am off to the new project ... ;)

02.10.2009 | Comments [0]
Flokkur: Agile | Forritun | Scrum | XP
Höfundur: Petar Shomov

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