Meine Werkzeuge – Evernote das Protokollmonster

Wenn es darum geht, Mitschriften und Notizen zu erfassen um diese schnell im Zugriff zu haben und auch einfach an Teamkollegen weitergeben zu können, dann setze ich Evernote ein.

Da ich inzwischen schon mehr als ein Jahr konsequent mein iPad als mobilen Arbeitsplatz nutze und auch keine Scheu mehr habe, es beim Kunden einzusetzen (der Trend-Faktor ist so langsam vorbei ;-), ist Evernote aus meinem Arbeitsalltag nicht mehr wegzudenken.

Dabei nutze ich fast ausschließlich die Texterfassung und die kleinen Formatierungsoptionen wie Checkboxen oder Aufzählungen. Ab und an wird mal eine Flipchart Skizze mit fotografiert und eingebunden.

Von Audio Aufzeichnungen nehme ich Abstand, weil es aus meiner Sicht datenschutzrechtlich bedenklich ist und außerdem ziemlich umständlich ist, auf die Information wieder zuzugreifen.

Ich bin gespannt, was passiert, wenn Evernote die Funktionen von Penultimate mit einführt, was ja vor kurzem übernommen wurde.

Werbung

Meine Werkzeuge – Wofür ich GoogleDocs nutze

In einem meiner letzten Projekte habe ich erstmals intensiver mit GoogleDocs gearbeitet. Und ganz ehrlich: ich war begeistert von den Möglichkeiten, die Google hier bietet. Das macht Office um einiges ersetzbarer.

Die Anforderung bestand darin, die in der Testphase des Entwicklungsprojektes anfallenden Testergebnisse strukturiert zu erfassen und in den regelmäßigen Statustelkos abstimmen zu können.

GoogleDocs bietet im Spreadsheet eine Formularfunktion, die es ermöglicht, dass bestimmte Nutzer ausschließlich Daten über ein vorher definiertes Formular eintragen können. Also habe ich ein Formular für Testberichte erstellt, welches es den Testern ermöglichte, schnell und einfach aus vordefinierten Listen auszuwählen, Checkboxen anzuklicken und eigene Kommentare zu hinterlassen wo es erlaubt war.

Das Projektteam konnte die eingetragen Testberichte quasi in Echtzeit sichten, kommentieren und den Status verändern.

In den Statustelkos hatten dann alle relevanten Teilnehmer das Spreadsheet online verfügbar. Je nach Berechtigung waren einzelne Spalten nur lesbar oder auch bearbeitbar. Dort wurden dann während der Telko die Anmerkungen und Hinweise eingetragen, so dass am Ende der Telko bereits das von allen gemeinsam verabschiedete Testprotokoll mit den zugeteilten Aufgaben zur Verfügung stand.

Der Aufruf von GoogleDocs via iPad, Laptop oder sogar Smartphone bot die Möglichkeit, jederzeit schnell einen aktuellen Status abzurufen.

Die Benachrichtigungsfunktion sendete täglich eine Zusammenfassung der Änderungen am Spreadsheet so dass ich morgens bereits informiert war, was am Abend oder in der Nacht durch die Entwickler noch bearbeitet worden war oder welche neuen Meldungen eingetragen wurden.

KANBAN hat eine Retrospektive!

Wie jeden Tag habe ich auch heute wieder etwas dazu gelernt.
Henning Wolf und Arne Rook von it-agile haben heute bei der GPM Regionalgruppe eine Einführung in KANBAN und Scrum gegeben.
Und was musste ich da hören? KANBAN hat eine Retrospektive! Verdammt, das hab ich echt vergessen bei der Einführung bei der ABIAN.
Eigentlich aber logisch, schließlich ist das Kaizen ein Kern der Lean Philosophie.
Das hole ich jetzt natürlich schnell mal nach 😉
Und wenn ich so ein bisschen drüber nachdenke dann merke ich, dass diese Retrospektive bei den Teams schon von alleine begonnen hat, ich sollte bloß mal mitmachen.
Was mich wiederum freut, denn es zeigt doch, dass die Jungs schon „Lean“ leben.
Zur eigenen Erinnerung nochmal die vier Grundprinzipien von KANBAN:
– Visualisierung
– Limitierung (WIP)
– Pull Prinzip
– Kaizen

Wie überzeuge ich meinen Kunden von Scrum?

Eine Frage, die wir im Februar auf dem it-Camp von oose diskutiert haben, will mir nicht aus dem Kopf: wie bringe ich denn meinen Kunden dazu, das Experiment Scrum zu wagen?

Klar, ich kann ihn mit Argumenten und Literatur überschütten. Und das Killerargument Nummer 1: die Anderen machen das ja auch.

Aber mal eine andere Idee: Warum denn nicht mal auf Belohnung für den Kunden setzen?

Meine Idee: Wir machen zunächst eine klassische Projektkalkulation. So wie wir sie brauchen, um ein Projektangebot zu erstellen. Und dann bieten wir dem Kunden an, dass wir das Projekt agil durchführen wollen und wir uns die eingesparten Kosten mit ihm teilen.

Das wär doch mal was, oder?

Dat wusste ich nich….

Weder kannte ich Fritz B. Simon noch die systemische Organisationstheorie mit der er sich beschäftigt. Diese Wissenslücke durfte ich heute füllen – und es hat sich gelohnt. Auf dem oose it-camp in Hamburg hat Fritz B. Simon einen sog. „Impulsvortrag“ gehalten, um die Teilnehmer auf den Rest des Tages einzustimmen. Das ist, zumindest bei mir, voll gelungen.

Kanban in der IT (Part 1 – Systemhaus)

Seit zwei Monaten kann ich erste praktische Erfahrungen im Einsatz von KANBAN Prinzipien in der IT sammeln. Sowohl in der Softwareentwicklung als auch im klassischen Systemhausbereich der Firma ABIAN GmbH in Hannover habe ich ein KANBAN Board eingeführt.

Experiment SCRUM

Jetzt sind wir drin im ersten SCRUM Projekt. Ich werde hier unregelmäßig meine Erfahrungen mitteilen.
Die ersten Erfahrungen mit Scrum zeigen mir folgendes:
1. Die Entwickler sind wirklich motiviert. Das macht Spaß!
2. Wir alle müssen uns an die Disziplin und das Timeboxing in SCRUM gewöhnen. Von wegen AGIL=alles ist frei 😉
3. Vieles aus dem guten alten IPMA Kurs findet man wieder – heißt halt nur anders. Ist ja schließlich das „hippe“ Scrum.
4. Als Product Owner muss ich ja noch mehr mit dem Kunden sprechen als vorher als Key Accounter. Uff.
5. Whiteboards kann man nie groß genug planen.
6. Ralf Wirdemanns Buch „Scrum mit User Stories“ liefert uns jede Menge Input und auch Diskussionsstoff. Leider fällt mein Exemplar schon fast auseinander. Gut dass es das ebook dazu gibt.
7. User Stories sind wirklich ein gutes Mittel um die Anforderungen zu abstrahieren und der Kunde besteht es tatsächlich.

Die alten Scrum Hasen werden jetzt sicher grinsen – aber allen anderen kam ich nur Mut machen es zu probieren.

Agil nach innen – klassisch nach außen?

Habe heute einen interessanten Artikel zum Thema Agile Entwicklung vs. V-Modell XT gelesen. Interessant deshalb, weil ich mir gut vorstellen kann, so das immer wieder auftretende Problem zu lösen: Wie sag ichs meinem Kunden?
Immer wieder stehe ich vor dem Problem, dass meine Kunden nur den klassischen Weg kennen und ihn auch nur ungern verlassen wollen. Sie wollen zur eigenen Absicherung ein Pflichtenheft, einen Projektplan, ein Angebot mit einem konkreten Projektpreis.
Und all das passt ja dann doch nicht so ganz zu SCRUM als agilem Vorgehensmodell. Klar: ich habe mein Backlog, ich habe Releases, aber ich habe keine angeblich „verlässliche“ Featureliste für die Leistungsebene. Ich habe auch keinen Preis für die definierten Inhalte des Pflichtenheftes sondern nur ein Budget, welches meiner Zeit und Ressourcenplanung für die Sprints entspricht.
Da klingt der Vorschlag, die beiden Weten miteinander zu verbinden, verführerisch.
Mal sehen, ob ich eine Projekt mal so angehe.