Commit every day, or revert – Be agile, every day

One of the biggest problems in agile development teams is “effort”. Of course it is always about effort, because effort is money and we all like our money. In planning we can cope with effort quite easily: “oh that’s a week effort”, but when it comes down to “what to do today” we start struggling. And how can we complete the “one week effort” if we struggle with our daily work?

My proposal for solving this issue is: At the end of the day, whatever you have done this day, if it is not complete, throw it away!

How can I do such a statement? I believe that every single task can be done in a day. Many agile and iterative processes take care that tasks are small. But none does enforce that a task has to be finished in one day, but allow that tasks can run longer. The additional pain involved in throwing away work takes care that everybody gets more aware of what value they create a day. If a single task takes longer than a day this can have three main reasons:

The task is way too big

This is obvious, and sounds contradicting to the assumption that every task can be done in a day, but on closer look it is just about the correct definition of a task. Throw away what has been done and split the task. Note that whatever has been done is not wasted. Because it was not clear in the beginning that this task would take longer than a day, there has been too less knowledge about this task. At the end of the day there is enough knowledge gained to make smaller tasks. Be reminded: There is always a unit of work that can be done each day.

Progressing with the task is blocked by others

Do not sit down and wait. Take another task. Resolving the impediment can be done earliest next day, and the solution will be available earliest in the day after. During that time two other tasks could have been finished. Ideally find out if there is a unit of work that you can finish before moving on.

A simple task takes too long

My favorite. It is very much possible that the developer is heading into the wrong direction. Throw the futile coding away and restart the next day. Although managers might not believe in this, I see many developers nodding, knowing that when you are stuck its easier to restart. In most cases code quality and efficiency is also better.

Is this wasting time? No it is learning! Learning to create manageable tasks. It also will lead to more accurate task definitions. Even when there will be a higher rate of “revert” after implementing this philosophy, it will rapidly decrease. Awareness of the actual tasks, the value they contribute and the quality of the result are easier to check. And the effort gets manageable, because the “oh a week of effort” could be identified as 3 days effort.

There are also a lot more aspects on this. By either committing code every afternoon, or throwing it away it is made sure that the codebase for every developer is identical each morning. Merging code is easier, and incompatible changes are less likely. Also it is less likely that two or more people solve the same issue. Besides these technical advantages this also frees developers mind for a relaxed evening. And there is no need to remember all the details from the day before.

Why not?

The most common counter argument against this is, that it is impossible to define a whatever complicated task so that it can be done in a day. This cannot be true, because there has to be a starting point somewhere, and after sitting down 4 hours, something has been done. Even after 10 minutes already something has been done. A “unsplittable” 2 week task, can and has always to be split to 10 working days. The point is that not the average developer has to do this split in his head, and deliver after 2 weeks, but all involved people do this. And thus results are visible next day already. And it enables also less skilled developers to contribute resolving more complicated user stories.

This article has been written on a single day, reviewed on another, translated on the third and published on the fourth day. At the end of each day something was done.

  • Facebook
  • Delicious
  • Digg
  • StumbleUpon
  • Reddit
  • Blogger
  • LinkedIn
Fabian Lange

5 Responses to Commit every day, or revert – Be agile, every day

  1. Hi Fabian,
    der Aussage es sollte jeden Tag committet werden pflichte ich bei. Wenn man den ganzen Tag entwickelt, sollten kommen in meiner Erfahrung so ca 10 commits dabei heraus.

    Die harte Forderung (wenn sie denn so hart ist) angefangene Arbeit am Ende des Tages wegzu werfen halte ich für nicht sinnvoll (wie die meisten harten Regeln) Wenn eine Aufgabe 60 Minuten dauert, aber ich nur noch 30Minuten Zeit habe, fange ich sie dennoch an, und mache sie am nächsten Tag fertig.

    Jens

  2. Fabian Lange says:

    Hallo Jens,
    Ja.. und nein :-) Natürlich ist das keine realistische Forderung, sondern eher als mahnendes Beispiel zu sehen. Ausgehend von einer Situation wo man es nicht schafft Aufgabeneinheiten für einen Tag zu finden.

    Aber auch bei Deinen 30 Minuten kann man fragen: Gibt es nicht etwas was abgeschlossen realisierbar ist? Oder mag man dann nicht einfach eher nach Hause gehen können?
    Eine Teilidee ist es ja den Kopf freizumachen und sich ebend nicht noch was merken zu müssen (wir merken uns eh schon zu viel [bei mir ist ne Komplettlösung von Monkey Island im Kopf die ich nicht weg bekomme :-) ])

    Und zuletzt: Es ist deshalb so radikal formuliert damit es im Gedächtnis bleibt

  3. Friedel says:

    Als Idee und Ideal taugt diese Forderung denke ich schon. Aber birgt das nicht die Gefahr, dass man groessere Aenderungen unnoetig zerteilt? Die Antwort lautet, dass es vom Entwicklungsprozess abhaengt. Ein Commit beinhaltet in meinem Umfeld, eine lauffaehige Software zu haben, die mit keinem anderen Modul in Konflikt steht. Wenn also Interfaces veraendert werden, muss die zum naechsten Commit auf beiden Seiten vollzogen sein. Daher kommt es vor, dass man manchmal mehrere Wochen seinen Code in die Integration geben kann. – Das ist aber wie gesagt eine Prozesshuerde, die den Commit verhindert – nicht jedoch, dass man versuchen sollte, eine Teilaufgabe am Abend fertig zu haben.
    Daher stimme ich dir trotzdem voll und ganz – alleine deswegen, damit man sich am naechsten morgen nicht ueberlegen muss, wo man gestern aufgehoert hat.

    • Wenn man bedenkt, dass es mittlerweile auch die “Strömung” von nano-commits gibt, denke ich dass die Forderung wenigstens einmal am Tag zu commiten nicht übertrieben ist. Nano-commits finden in der Testgetriebenen Entwicklung entwicklung bei jedem “grünen Balken” statt, also immer, wenn alle Tests funktionieren. Dadurch werden eventuelle synchronisations/merge-Aufwände und Risiken weiter reduziert. Ich denke auch eine Interface-Änderung kann man, wenn man darüber nachdenkt, in kleinere Schritte zerteilen, die jeder für sich schon Wert generieren und Risiko minimieren.

  4. Thomas Jaspers says:

    Da hat Fabian ja ein sehr interessantes Thema aufgegriffen und ich kann auch durchaus die Bedenken verstehen, zumal man im Projektstress evtl. nicht immer sofort sieht, wie umfangreiche Änderungen gut gesplitted werden können.

    Aber gerade bei Interface-Änderungen denke ich es bietet sich oft an diese in drei Schritten einzuführen:

    1. Neues IF parallel zum bestehenden IF anbieten.
    2. Client(s) updaten auf das neue IF.
    3. Das alte IF entfernen.

    Klingt erstmal aufwendig, aber ich bin überzeugt es ist insgesamt weniger Aufwand, da deutlich weniger Absprachen nötig sind und weniger Synchronisationsaufwand betrieben werden muss. Auch ist die Gefahr eines am Ende doch “gebrochenen Builds” deutlich geringer :-).

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>