Posts filed under ‘#’

Handling Impediments with the Task Board

My colleague Bernd Schiffer has published an interesting article about managing impediments with an Action Board (see his blog post). I think it is valid to have such an Action Board and it is definitely superior to what a lot of teams do: The ScrumMaster records impediments in a personal notepad.

But I prefer a simpler mechanism and just adding impediments to the existing Task Board which I have described here in a PDF.

September 5, 2011 at 9:07 am 1 comment

Einfaches Scrum

Dies ist die Übersetzung des Blog-Artikels „Simple Scrum“ von Tobias Mayer in der Version vom 01.01.2010 (http://agileanarchy.wordpress.com/2009/09/20/simple-scrum/).

Die Übersetzung habe ich (Stefan Roock, stefan.roock@it-agile.de) vorgenommen. Ich habe mich entschieden. an einigen Stellen leicht vom Original abzuweichen mit der Absicht, einen Sachverhalt einfacher zu erklären.

Ich denke an Scrum als etwas fast unfassbar Einfaches, das häufig unnötig verkompliziert wird. Es ist diese Verkomplizierung, die so viele Missverständnisse verursacht und zu schlechten Anwendungen von Scrum führt. Die folgende Beschreibung von Scrum hat das Ziel, Scrums Geist der Einfachheit einzufangen.

Scrum ist ein Framework, um die Art und Weise zu verbessern, in der Menschen arbeiten, oder wie auf der Scrum Alliance-Website definiert „ein team-basiertes Framework zur Entwicklung komplexer Systeme und Produkte“. Scrum benutzt einen iterativen Prozess in dem die Iterationen (aka Sprints) so kurz wie sinnvoll möglich gehalten werden. Die Sprints erzeugen einen gleichmäßigen Rhythmus der durch Planung, Durchführung und Reflektion pulsiert. Diese strikten, rhythmischen Time-Boxen von Scrum fördern auf frappierende Weise organisatorische Dysfunktionen zu Tage.

Scrum definiert drei Rollen (Scrum Master, Product Owner und Team), erfordert eine priorisierte Menge von Zielen, ein Commitment für jeden Sprint und eine einfache Art, Fortschritt zu messen. Scrum benutzt Zeremonien mit Timeboxen, um zu planen und auf täglicher sowie Sprint-Basis zu inspizieren und zu adaptieren.

Das „Was“ (das Ziel) und das „Wie“ (der Weg) werden klar unterschieden. Scrum erfordert klaren Fokus, Commitment und vollständige Transparenz auf allen Ebenen; es hebt auf bestimmte menschenzentrierte Werte ab, einschließlich (aber nicht eingeschränkt auf) Vertrauen, Integrität, Mut und Respekt.

Rollen
Der ScrumMaster ist eine dienende Führungskraft (Servant Leader) für das Team und ein Change Agent in der Organisation. Der Product Owner ist die Hauptstimme des Kunden, etabliert eine fesselnde Vision und benutzt einen Prozess kontinuierlicher Priorisierung, um die Vision umzusetzen. Das Team ist eine selbstorganisierte, cross-funktionale, bevollmächtigte Gruppe, die die Vision in das Produkt oder den Service umsetzt.

Artefakte
Ein Backlog (Auftragsbestand) aus Anforderungen oder Zielen ist immer vorhanden. Es enthält zu jeder Zeit all die Dinge, von denen wir möchten, das das Produkt oder der Service sie enthalten. Es ist eine lebendige Liste, kontinuierlich im Fluss und trotzdem jederzeit nach Priorität geordnet, die sich über die Zeit ändern wird. Die Einträge des Backlogs fokussieren auf das „Was“. Das Sprint-Commitment ist eine Untermenge des Backlogs, manchmal herunter gebrochen auf Arbeitsaufgaben (Tasks), die das „Wie“ beschreiben. Scrum fordert einfache Metriken, z.B. die verbleibende Restarbeit oder gelieferter Geschäftswert. Diese Metriken sollten verwendet werden, um die Wirklichkeit zu erfassen – nicht, um Erfolg oder Misserfolg zu festzustellen. Nur Metriken der Wirklichkeit können wir vertrauen, dass sie dem Team keinen Anreiz für Quick-Fix-Verhalten geben.

Zeremonien
Das Team und der Product Owner treffen sich vor dem Start jeden Sprints, um die Arbeit zu planen. Das Team committet sich auf priorisierte Arbeitspakete, die „wohldefinierte Ergebnisse“ (das Ziel) haben und es wird von ihm erwartet, dass es das fertige Produkt gemäß diesen Kriterien am Sprintende liefert. Wie das Team seine Arbeit erledigt (der Weg) ist allein ihm überlassen. Jeden Arbeitstag treffen sich die Teammitglieder an einem visuellen Board (z.B. Taskboard), um sich abzustimmen und Hilfe einzufordern und anzubieten. Am Ende jedes Sprints begutachten Stakeholder und Konsumenten die abgeschlossene Arbeit und machen Vorschläge für Anpassungen. Nach dem Review reflektieren die Teammitglieder über ihren Prozess, suchen nach Verbesserungsmöglichkeiten und committen sich auf Veränderungen ihrer Arbeitsweise. Jeder Sprint produziert ein verbessertes Produkt oder einen verbesserten Service und – sogar noch besser – ein glücklicheres Team.

Das ist mehr oder weniger die Beschreibung von Scrum, die seit der Veröffentlichung des ersten Scrum-Buchs 2003 existiert. Ich habe sie aus dem Software-Kontext herausgelöst, einige Begriffe fallen gelassen, um auf die grundlegenden Prinzipien zu fokussieren und versucht, sie auf ihre Essenz zu kondensieren. Ich habe nichts hinzugefügt oder weggelassen.

August 18, 2011 at 3:14 pm 2 comments

2010 in review

The stats helper monkeys at WordPress.com mulled over how this blog did in 2010, and here’s a high level summary of its overall blog health:

Healthy blog!

The Blog-Health-o-Meter™ reads Wow.

Crunchy numbers

Featured image

A Boeing 747-400 passenger jet can hold 416 passengers. This blog was viewed about 13,000 times in 2010. That’s about 31 full 747s.

 

In 2010, there were 41 new posts, growing the total archive of this blog to 506 posts. There were 37 pictures uploaded, taking up a total of 21mb. That’s about 3 pictures per month.

The busiest day of the year was January 7th with 150 views. The most popular post that day was Festpreise und schneller durch Scrum.

Where did they come from?

The top referring sites in 2010 were stefanroock.de, blogs.isixsigma.com, twitter.com, google.de, and stefanroock.blogspot.com.

Some visitors came searching, mostly for stefan roock, prolog cut, code kata, webcastellum, and roock.

Attractions in 2010

These are the posts and pages that got the most views in 2010.

1

Festpreise und schneller durch Scrum January 2010
4 comments

2

Kanban: Definition of Lead Time and Cycle Time March 2010
7 comments

3

Code Kata Bunkai: Prime Factors January 2010
11 comments

4

Profil ansehen February 2009

5

Scrum vs. Kanban: Ziel und Weg March 2010
4 comments

January 2, 2011 at 12:49 pm Leave a comment

Clojure lernen

Um gedanklich nicht einzurosten, sehe ich mir dann und wann eine neue Programmiersprache an. Diesmal war Clojure an der Reihe. Clojure ist eine funktionale Sprache, die auf der Java VM läuft. Und letztlich ist Clojure nicht wirklich eine neue Programmiersprache, sondern ein Lisp-Dialekt. Clojure bietet an der einen oder anderen Stelle syntaktischen Zucker, so dass der Quelltext etwas aufgelockerter aussieht (nicht soviele runde Klammern) und dadurch für Lisp-Neulinge leichter lesbar ist. Ansonsten ist Clojure aber ein vollständiges Lisp, das sich im Gegensatz zu Common Lisp aber zu beschränken weiß: kein Mega-For-Konstruktur, kein CLOS, etc. Und einige Antiquitäten sind moderneren Einrichtungsmöbeln gewichen: car heißt jetzt first und cdr heißt tail.

Ich finde, das Resultat ist eine einfache, fokussierte Sprache, die einfach zu lernen ist und Spaß macht. Dazu trägt auch bei, dass Clojure bewusst funktional ist und kein OO-Hybrid. So wird man als OO-Entwickler gezwungen, sich einer anderen Perspektive beim Programmieren zu öffnen und das ist auf jeden Fall nützlich – und sei es nur zur Horizonterweiterung.

Neben der eigentlichen Sprache bietet Clojure einige eigene Bibiotheken, insbesondere für die Programmierung paralleler Algorithmen. Durch die funktionale Struktur von Clojure-Systemen gestaltet sich dieses Themengebiet in Clojure viel einfacher als z.B. in Java. Ich bin zwar der Meinung, dass parallele Algorithmen im Moment deutlich überschätzt sind. Aber wenn man meint, dass man es braucht, dann sollte man sich Clojure auf jeden Fall mal ansehen.

Und wenn man keine parallelen Algorithmen braucht, sollte man sich Clojure auch ansehen und z.B. die eine oder andere Code-Kata in Clojure programmieren. Es hat schon seinen eigenen Charme, vollständig funktional zu programmieren.

 

 

November 22, 2010 at 7:19 pm 3 comments

Train the Trainers: “Training from the back of the room”

Thursday and Friday of this week I attended the train the trainers event “Training from the back of the room” that was appended to the Scrum Gathering in Amsterdam. The training with Sharon Bowman was awesome.
I had already read the first half of her book (“Training from the back of the room”) but the training itself showed me how radical the concept really is meant. I have the subjective impression that Sharon talked less then 60 minutes during the two day training. The rest of the training was done by the 35 participants – everybody in action all the time. Everybody walked, talked, wrote and discussed all the time. This type of training reflects current brain research insights. Sharon describes the principles with 6 trumps:

  1. Movement trumps sitting. So we moved all the time and sat down very seldom.
  2. Talking trumps listening. We talked in pairs or in small groups during the whole training.
  3. Images trump words. Whenever possible Sharon used drawings, metaphors, stories etc.
  4. Writing trumps reading. We read few things and wrote down insights individually or as a workgroup.
  5. Shorter trumps longer. The content delivery was split up in very small chunks, each shorter than 10 minutes.
  6. Different trumps same. We applied lot’s of different practices to learn the content.

I highly recommend the training and the book to everybody who does training.

November 21, 2010 at 1:35 pm 3 comments

The Liskov Substitution Principle (LSP) in duck typed programming languages

This article is the follow up to a Twitter conversation in which at least @johanneslink, @jasongorman, @leiderleider and @berndschiffer were involved. The question was if the Liskov Substitution Principle would apply if you don’t use inheritance. I had to stop participating in the Twitter conversation since 140 character messages are just too short to explain my point of view. Here is the longer version:

The Liskov Substitution Principle
The Liskov Substitution Principle (LSP): “[…] states that, if S is a subtype of T, then objects of type T in a computer program may be replaced with objects of type S (i.e., objects of type S may be substituted for objects of type T), without altering any of the desirable properties of that program (correctness, task performed, etc.).” (Source: Wikipedia).
The more formal definition of the LSP is: “Let q(x) be a property provable about objects x of type T. Then q(y) should be true for objects y of type S where S is a subtype of T.” (Source: Wikipedia).
And to be complete, here is the definition of subtype: “In programming language theory, subtyping or subtype polymorphism is a form of type polymorphism in which a subtype is a datatype that is related to another datatype (the supertype) by some notion of substitutability, meaning that program constructs, typically subroutines or functions, written to operate on elements of the supertype can also operate on elements of the subtype.” (Source: Wikipedia).

While subtype and LSP sound similar, there is a difference: The subtype relation normally is interpreted as a syntactical property. If the required methods are available on an object, everything is valid. The Liskov Substitution Principle goes beyond that and adds a requirement on the semantics of the methods.

Example (in pseudo code)

class A {

    public void m() { ... do something ... }

}

class B extends A {

    public void m() { 
        throw new Exception();
    }

}

In this case B is a subtype of A. B has the same methods as A. But the LSP may be violated. If the clients of A expect m to not throw an exception, B’s implementation of m breaks the LSP. Regarding the formal definition of the LSP (“Let q(x) be a property provable about objects x of type T.”). The property q would be that the execution of m won’t throw an exception. This property is true for A’s implementation of m but not for B’s implementation of m. Therefore you shouldn’t use objects of class B where a client expects objects of class A. While that would be syntactically correct it isn’t semantically valid.

The Liskov Substitution Principle in class typed languages
In most statically typed object-oriented languages (like C++, Java, C#) the subtype relation is defined by inheritance between classes. When a class B inherits from a class A the defined type B is a subtype of A. The example above showed that the LSP may be violated due to specific method implementations provided by B.
Some languages (like Java) provide an interface concept. Interfaces only define the signature of methods but don’t provide method implementations. Classes implement interfaces and provide the method implementations. With interfaces the LSP is still a useful concept. The clients of an Interface C rely on a certain behaviour of the objects implementing the interface. Again the clients of C may assume that m won’t throw exceptions.

interface C {

    public void m();

}

class A implements C {

    public void m() {
        throw new Exception();
    }

}

In the example code A’s implementation of m will break the LSP.

These situations are clear and well understood. But what happens in programming languages with duck typing (like Ruby)?

The Liskov Substitution Principle in duck typed languages
In programming languages with duck typing (e.g. Ruby, Python, Smalltalk) classes don’t really define types. There is no type checking when assigning objects to variables or passing objects as method arguments. There is a kind of type checking when a method is called. It is checked that the method exists with a matching number of parameters.
Since classes don’t define types, inheritance in duck typed languages has nothing to do with the subtype relation or the LSP.
In a way clients define interfaces in an implicit way. Let’s look at an example:

def my_method1(a) do
    a.m1()
    a.m2()
    my_method2(a)
end

def my_method2(a) do
  a.m3()
end

Calling my_method1 with an object a will succeed if the object a provides the three methods m1, m2 and m3. This is the implicit interface the object a needs to implement. And with this implicit interface comes the clients expectation about the behaviour of m1, m2 and m3. That’s just the same as with the Java interface. If an object b provides m1, m2 and m3 but doesn’t fit the expected behaviour, the LSP is violated.

Conclusion
The LSP isn’t tied to inheritance or class based typing. It applies to duck types languages as well as to systems without inheritance. LSP is a concept that applies to all kinds of polymorphism. Only if you don’t use polymorphism of all you don’t need to care about the LSP.

November 8, 2010 at 10:16 am 2 comments

Meine Mac-Erfahrungen

Vor gut einem halben Jahr habe mein IBM/Lenovo Thinkpad-Notebook mit Ubuntu eingetausch gegen ein MacBook Pro. Zeit genug, um ein vorläufiges Resume zu ziehen. In meiner persönlichen total subjektiven Bewertung liegt der Mac eine Nasenlänge vor Thinkpad mit Ubuntu. (Beide liegen um Längen vor Windows, auch vor Windows 7).

Im Einzelnen (+ bedeutet, dass es besser ist als Thinkpad/Ubuntu, – bedeutet, dass es schlechter ist, = bedeutet, dass es ungefähr gleich ist):

Gehäuse
+ Aluminium fühlt sich edel an
– sieht aber mit etwas Abstand eigentlich genauso aus wie billiges Plastik
– ist etwas rutschig, wenn man zugeklapptes Gerät aufrecht trägt
– lädt sich bei passendem Wetter elektrostatisch auf, so dass man beim Anfassen manchmal leichte Stromschläge bekommt
– mattes Display kostet Aufpreis
+ Akku kann man nicht einfach so austauschen und es gibt anscheinend keinen Zweitakku
– es gibt keine Docking-Station, aber fast alles ist USB also tut es auch ein USB-Hub

Tastatur
+ beleuchtet
– Return-Taste sehr klein
– Cursor-Tasten sehr klein
– kein POS1/Ende: Im Prinzip durch andere Tastenkombinationen ersetzbar, aber die sind nicht in allen Apps verfügbar oder kollidieren mit Spaces
– keine Page-Up/Page-Down-Tasten
– Anschlag: nicht so gut wie bei Lenovo Thinkpad, aber besser als bei Billig-Dell
= Was auf PC “Ctrl” heißt hier “Cmd” und “Ctrl” auf dem Mac ist was ganz anderes. Daran habe uch mich aber schnell gewöhnt.
– []|{} ist nicht auf die Tasten drauf gedruckt. Ich weiß, wo die Zeichen sind, habe beim Tippen aber doch immer eine leichte Verzögerung.

Trackpad
+ sehr groß und dadurch gewöhnungsbedürftig: am Anfang hatte ich da immer mehrere Finger drauf und habe versehentlich Gesten ausgeführt; daran habe ich mich aber schnell gewöhnt und habe jetzt Probleme mit den kleinen Trackpads der PC-Notebooks
+ durch die Größe arbeitet man eher mit beiden Händen (eine für Bewegung, eine für Klicken, was wiederum ganz angenehm sein kann)
+ Gesten für Scrollen, Zoomen, Drehen etc.

Sleep-Mode
+ Der Rechner erwacht super-schnell aus dem Sleep-Mode.

Betriebssystem/Oberfläche
+ die allermeisten Mac-Programme haben eine sehr gefällige und einheitliche Optik. Das ist deutlich angenehmer als unter Ubuntu.
– Spaces kommen nicht an Linux heran: sind mit der Maus nur umständlich zu benutzen
– Spaces: keine Visualisierung der offenen Fenster in der Menüleiste, dadurch schlechte Übersicht, was man wo auf hat
+ Dock: Nett
= Drucken ging nicht auf Anhieb mit MP620; ich musste Treiber bei Canon runterladen; immerhin gibt es welche für Mac und sie funktionieren auch gleich einwandfrei
= Spot-Light ist nützlich (ähnlich dem Ubuntu-Äquivalent)
– Finder kann kein FTP/SFTP (im Gegensatz zu Ubuntu Nautilus)
– Der Finder hat insgesamt ein paar nette Features und teilweise total verwirrendes Verhalten. Das scheint mir mal ein Komplett-Rewrite angesagt.
– Nach wir vor finde ich merkwürdig und auch eher störend, dass Programme weiterlaufen, auch wenn alle Fenster geschlossen sind.
– Die Anzeige der Akku-Restlaufzeit scheint mir ziemlich erratisch. Nach dem Laden des Akkus zeigt der Mac 5:30 Stunden an. Nach 30 Minuten harmloser Aktivität sind noch 2 übrig.

Applikationen
+ Skype ist einfacher zu installieren als unter Ubuntu; Video funktioniert auf Anhieb; keine Audio-Probleme
+ DVD geht sofort. Allerdings hat der mitgelieferte DVD-Player deutliche Usability-Defizite (z.B. beim Einschalten des Vollbild-Modus)
– MPEG, WMV gehen nicht auf Anhieb und man muss Zusatzkram im Internet finden und runterladen
– Safari öffnet Links immer in neuen Fenstern und man kann das in Safari selbst nicht umstellen. Wenn man “defaults write com.apple.Safari TargetedClicksCreateTabs -bool true” in der Console startet und dann Safari neu startet, werden Links in Tabs geöffnet. Das ist mir alles zu nervig und ich benutze dann doch lieber Firefox auf Mac.
– Installation von Komponenten und Software ist in Ubuntu über das Software-Center viel eleganter gelöst als auf Mac. Aber vielleicht macht Apple hier ja mit dem geplanten Mac-App-Store Boden gut.
+ Synchronisation mit dem iPhone geht unter Mac natürlich nahtlos und ist unter Ubuntu leider eine ziemliche Katastrophe. Ubuntu erfordert eigentlich ein Android-Handy.

Programmierung
+ Ruby/Rails gleich drauf
= Installation aber sonst wie Linux: Compilefehler bei gem install webrat, weil man erst 2,5 GB XCode-Kram installieren muss
– Vervollständigung mit Tab in der Shell funktioniert nur Top-Level, aber nicht mehr danach (git pull origin master)
– Für Navigation in einer Zeile in der Shell muss man sich eigene Tastenkürzel merken oder irgendwas konfigurieren, was ich nicht verstanden habe.
+ TextMate ist ganz cool

Wie gesagt, meine persönliche Bewertung für meine speziellen Einsatzkontexte. Ich nutze z.B. durch meine Reiserei viele Multimedia-Funktionalitäten (DVD im Hotel), Skype zum Telefonieren etc. Wenn ich den Rechner nur zum Programmieren verwenden würde, würde ich Ubuntu den Vorzug geben.

October 8, 2010 at 6:35 pm 4 comments

Older Posts