Open Space der Usergroup „Agile Rhein-Main“ am 21.4.2012

Es war auf dem Rückweg vom „Community Day“ einer Konferenz im vergangenen Jahr. Mit meinen Kollegen von //SEIBERT/MEDIA komme ich zu dem Schluss, dass das Open-Space-Format des „Community Day“ mindestens so wertvoll war wie die Vorträge von den Vortagen. Die Vielfalt der Themen und die Interaktion der Sessions haben den Tag unglaublich kurzweilig und lehrreich gemacht.
Keine Frage, so etwas brauchen wir auch im Rhein-Main-Gebiet.

Gemeinsam mit Benjamin Reitzammer, Reto Kiefer und Joachim Seibert von der Agile Usergroup Rhein-Main haben wir in den letzten Wochen die Rahmenbedingungen abgestimmt und laden nun am 21.4.2012 zum 1. Agile Open Space Rhein-Main nach Wiesbaden in die Räumlichkeiten von //SEIBERT/MEDIA ein.

Was ist ein Open Space?

Um es auf den Punkt zu bringen: Wir bieten den Rahmen, Ihr sorgt für die Inhalte.

Bei einem Open Space gibt es keine vorab festgelegte Agenda. Jeder Teilnehmer bekommt die Möglichkeit, eigene Sessions zu seinen Wunschthemen einzubringen. Dies können vorbereitete Sessions sein, die eher den Charakter eines Kurz-Workshops haben, z.B. auch Dojos oder Katas. Aber auch Diskussionsrunden, bei denen der “Session-Host” nur das Thema einbringt und die Moderation der Session übernimmt, die Inhalte aber von allen Teilnehmern gemeinsam erarbeitet werden, sind üblich. Es gibt keine Verpflichtung, selbst Themen einzubringen, es kann sich auch einfach Sessions von anderen Personen angeschlossen werden.

Wir erhoffen uns ein breites Themenspektrum über Scrum, Lean, Kanban, XP, Agile, … in den unterschiedlichsten Ausprägungen.

Nicht zu kurz kommen soll dabei auch der lockere Austausch zwischen den Teilnehmern, etwa beim Mittagessen, so dass wir uns untereinander noch besser kennen- und voneinander lernen.

Anmeldung

Die Anmeldung zu diesem Event erfolgt über XING. Es wird bei Anmeldung eine Kostenbeteiligung in Höhe von 29 Euro für Verpflegung, Materialien und Organisation berechnet.

Hier geht es zur Eventseite bei XING.

Foto: von logicalrealist

——–
Immer auf dem aktuellen Stand bleiben? Neue Artikel gibt es über FacebookTwitter, E-Mail (oben rechts) oder RSS-Feed.

„Scrum & Kanban im Agenturgeschäft“ – Slides jetzt online

Im Rahmen des andrena ObjektForum berichtete ich am vergangenen Dienstag über Scrum & Kanban im Agenturgeschäft von //SEIBERT/MEDIA. Seit etwa eineinhalb Jahren nutzen wir in mehreren Teams intensiv die Möglichkeiten der agilen Softwareentwicklung und weiten die Ideen nach und nach auch auf das gesamte Unternehmen aus.

Durch die aktive Beteiligung der Zuhörer entwickelte sich der Vortrag zu einem eineinhalb-stündigen Dialog. Vielen Dank an alle, die dabei waren und auch an Kurt Jäger von andrena für die Ausrichtung und Moderation.

——–
Immer auf dem aktuellen Stand bleiben? Neue Artikel gibt es über FacebookTwitter, E-Mail (oben rechts) oder RSS-Feed.

Vortrag zu „Scrum & Kanban im Agenturgeschäft“ am 10.1. in Frankfurt

Für Agenturen mit ständig wechselnden Projekten stellt es eine besondere Herausforderung da, agile und schlanke Vorgehensweisen wie Scrum und Kanban anzuwenden. Dieser Vortrag beleuchtet, wie Agenturen Scrum und Kanban für die Verbesserung ihrer Abläufe einsetzen können, wann besser auf Scrum und wann besser auf Kanban gesetzt werden sollte, sowie die kritischen Erfolgsfaktoren bei der Einführung von „Agile“ in Unternehmen. Dabei werden u.a. Fragen wie diese beantwortet:

  • Lohnt sich die Einführung von agilen Vorgehensweisen?
  • Wie führe ich agile Vorgehensweisen im Unternehmen ein?
  • Welche Voraussetzungen für einen Erfolg bestehen?
  • Soll ich besser auf Scrum oder auf Kanban setzen?
  • Welche Fallstricke und welche Herausforderungen gibt es zu überwinden?
  • Wie kann ich Scrum und Kanban in nicht-Programmierprojekten einsetzen?
  • Wie werden wir zum agilen Unternehmen?

Datum und Zeit: 10. Januar 2012 um 18:30 Uhr

Ort: Saalbau Gallus, Frankfurt

Referent: Paul Herwarth von Bittenfeld

Moderation: Kurt Jäger (andrena objects ag)

Die Anmeldung erfolgt über die Website von andrena

 

——–
TIPPS UND TRICKS ZUM PRODUKTMANAGEMENT VON INTERNETANWENDUNGEN
Immer auf dem aktuellen Stand bleiben? Neue Artikel gibt es über FacebookTwitter, E-Mail (oben rechts) oder RSS-Feed.

Ist das Daily Standup für Teammitglieder zwingend?

Daily StandupVon Zeit zu Zeit erhalte ich Anfragen von Lesern, zu denen ich natürlich sehr gerne auch Rückmeldung gebe. Im aktuellen Fall handelt es ich um eine Frage, die uns vor längerer Zeit auch einmal bewegt hat: „Ist das Daily Standup für Teammitglieder zwingend?“
Gerne führe ich meine Gedanken hierzu aus, freue mich aber auch über Ergänzungen anderer Leser über die Kommentarfunktion.

Was ist ein Daily Standup?

Um alle Leser abzuholen, möchte ich noch einmal vorstellen, worum es sich bei Daily Standups eigentlich handelt. Daily Standups sind tägliche Kurzbesprechungen des Projektteams und einer der Grundbestandteile agiler Softwareentwicklung. In Scrum wird hierfür die Bezeichnung „daily scrum“ verwendet. Es ist ein fest verankertes Element in Scrum. Aber auch in Teams, die mit Kanban arbeiten, werden tägliche Standup-Meetings häufig eingesetzt.

Als Grundregel kann angesehen werden, dass dieses Meeting maximal 15 Minuten dauern sollte. Jeden Tag, zur selben Uhrzeit am gleichen Ort. In dieser Zeit beantworten alle Teilnehmer die folgenden Fragen:

  • Was wurde seit dem letzten Standup-Meeting gemacht?
  • Was wird bis zum nächsten Standup-Meeting erledigt?
  • Gibt es Hindernisse, Herausforderungen oder Optimierungsbedarfe, die angegangen werden sollten?

Optimalerweise findet dies an einem Taskboard statt, wie in obigem Bild dargestellt, damit alle auch direkt sehen können, von welcher Aufgabe der Kollege gerade spricht. Gemeinsam wird dann dieses Taskboard auch im Standup-Meeting aktualisiert, etwa erledigte Aufgaben verschoben.

Ist ein Teilnahmezwang für Daily Standups sinnvoll?

In der weniger agilen Praxis werden die Standup-Meetings häufig in Frage gestellt. So sind sowohl bei den Projektteams selbst als auch beim Management der Sinn und Nutzen nicht selten umstritten.

Zunächst einmal ist es meines Erachtens sinnvoll, den täglichen Einsatzbesprechungen eine ernsthafte Chance zu geben. Hat das Team also noch gar keine Erfahrung damit gemacht, wäre es ein guter Schritt, diese für einen längeren Zeitraum, zum Beispiel für 4 oder 6 Wochen oder bei Scrum-Teams für 2-3 Sprints einfach einmal auszuprobieren. Einen Zwang würde ich für nachteilig halten, da hier ganz klar mit Gegenwehr gerechnet werden muss. Vielmehr sollte das Team gemeinsam einen solchen Test-Zeitraum beschließen. Wenn dann negative, schlecht begründete Kritik auftaucht, kann derjenige darauf verwiesen werden, dass sich gemeinsam für eine Testphase entschieden wurde, die erst einmal abgewartet werden sollte. Wenn ernsthafte Verbesserungsvorschläge vorgetragen werden kann geschaut werden, dass diese möglichst schon frühzeitig mit in die Standups eingebracht werden.

Wir haben die Erfahrung gemacht, dass Standup-Meetings von Teammitgliedern insbesondere in den folgenden Fällen kritisiert werden:

  • Die Meetings ziehen sich ewig hin und kommen nicht auf den Punkt. Dann sollte darauf geachtet werden, dass die Timebox eingehalten wird und Themen, die nur einen kleinen Teil der Gruppe betreffen erst im Anschluss an das Daily Standup besprochen werden.
  • Es wird gar nicht zusammen gearbeitet. Wenn jeder eh an seiner eigenen Baustelle arbeitet, dann erscheint der gegenseitige Austausch natürlich überflüssig. In diesen Fällen steht das Team vor einer größeren Herausforderung und sollte sich eventuell einmal damit beschäftigen, wie Teamwork in der agilen Softwareentwicklung verstanden und angewendet wird.
  • Es fehlt eine Moderation. Bei Scrum-Teams macht dies häufig der Scrum-Master, die Moderation kann aber auch abwechselnd von Teammitgliedern übernommen werden. Es sollte aber immer klar sein, wer gerade Moderator ist und dieser sollte z.B. darauf achten, dass die Redeanteile möglichst ausgeglichen sind. Nur wenn auch alle zu Wort kommen, macht es für sie auch Sinn, sich an dem Meeting zu beteiligen.
  • Es fehlt eine feste Zeit und ein fester Ort. Wenn die Meetings nicht allen Teammitgliedern in Fleisch und Blut übergehen und einen festen Platz im Kalender aller Teammitglieder haben, geht unnötig viel Zeit dafür verloren zu klären, warum Kollege A und Kollegin B gerade noch nicht anwesend sind. Manche Teams arbeiten auch mit „Strafen“, falls jemand unentschuldigt fehlt oder zu spät kommt. Dies können z.B. 10 Cent für das Team-Sparschwein sein, die dann nach etwas sammeln in einen Kuchen für das Team investiert werden.
  • Probleme werden nicht angegangen. Wenn immer wieder die gleichen Herausforderungen auftreten oder ein Kollege im Standup jeden Tag das gleiche erzählt, da er offensichtlich ein Problem mit einer Aufgabe hat, sollten beim Team die Alarmglocken angehen und für eine dauerhafte Lösung gesorgt werden. Standup-Meetings sind eine gute Möglichkeit, kontinuierliche Verbesserungsprozesse anzustoßen.

Nach dem wir nun ein paar Jahre Erfahrung mit Daily Standups haben, kann ich mir kaum noch vorstellen, wie ein Team, dass sehr eng zusammen arbeitet, ohne diese kurzen Einsatzbesprechungen effektiv und effizient zusammen arbeiten kann.

Weitere Informationen zu Daily Standups:

Foto: tomnatt

——–
Immer auf dem aktuellen Stand bleiben? Neue Artikel gibt es über FacebookTwitter, E-Mail (oben rechts) oderRSS-Feed.

„Kanban und Scrum in der Praxis“ bei AOE Media in Wiesbaden

Am 20.10.2011 findet ab 19:30 Uhr das nächste Treffen der Scrum User Group Rhein-Main statt. Nach dem Special „Scrum & Kanban im Agenturgeschäft“ im Juni 2011, bei dem Joachim Seibert und ich die Nutzung von Agile am Beispiel von //SEIBERT/MEDIA präsentiert haben, wird es wieder ein Special zu „Kanban und Scrum in der Praxis“ geben.
Gastgeber sind die Kollegen von AOE Media in Wiesbaden.

Die Agenda für den Abend:

  • Begrüßung und Kurzvorstellung AOE media
  • Scrum im Einsatz bei Congstar
  • Kanban als Methode bei AOE
  • Diskussionsrunde: Vorteile und Gegenüberstellung Scrum vs. Kanban oder spezialisierte Teams vs. Generalisten
  • Offene Runde

Für Snacks und Getränke ist gesorgt.
Zum anschließenden Austausch und Socializing werden wir noch ein Lokal in unmittelbarer Nähe aufsuchen.

Die Anmeldung zu diesem Event erfolgt per XING. Ein besonderer Dank gilt bereits jetzt Joern Bock für die Ermöglichung dieser Veranstaltung.

Einen kleinen Vorgeschmack auf das Event bietet der Vortrag von AOE-Media-Mitarbeiter Andreas Demmer zu Kanban vom Webmontag #32.

Rückblicke auf die Veranstaltung

QR-Codes zur Aktualisierung von Taskboards – 7 Fragen an Matt Müller


Wer den Raum eines Softwareentwicklungs-Teams betritt, dass sich die Vorteile der agilen Softwareentwicklung zunutze macht, wird in der Regel eines sehen können – ein Taskboard mit Aufgabenbeschreibungen auf Karten, das vom Team zur Organisation der Aufgaben genutzt wird.
Immer wieder sind Besucher bei uns irritiert über diese Rückkehr zu Tafel und Papier, ausgerechnet in einer Softwareschmiede. Viele Teams setzen dabei neben dem Offline-Taskboard zusätzlich auf eine elektronische Aufgabenverwaltung. Die Verwaltung der Aufgaben an einem Taskboard im Teamraum sorgt für eine hohe Transparenz und macht den Arbeitsfluß in einem besonderen Maße sichtbar. Die Verwaltung von Aufgaben in einem elektronischen System hat ebenfalls ihre Vorteile. So lassen sich dort auch große Mengen von Vorgängen dauerhaft für die spätere Bearbeitung vorhalten, einfach mit Links und Grafiken versehen und es kann eine Anbindung an ein Zeiterfassungssystem erfolgen. Die Verwendung von beidem führt jedoch zu einer Herausforderung: Änderungen am Status einer Aufgabe (z.B. „offen“, „in Bearbeitung“, „geschlossen“) müssen in beiden Systemen, digital und analog, erfolgen.

Umso spannender fand ich es, bei meinem ehemaligen Kollegen Matthias Müller von einer selbst entwickelten Lösung für einen einfacheren Abgleich zwischen Taskboard im Teamraum und elektronischer Aufgabenverwaltung zu lesen.
Matthias hat sich bereit erklärt, mir ein paar Fragen zu seiner Lösung zu beantworten.

Matthias, erzähl‘ uns erst einmal wer Du bist und was Du machst.

Hallo Paul! Ich arbeite als Softwareentwickler bei der Rhein Main Multimedia GmbH in Mainz. Wir sind eine Tochtergesellschaft der Verlagsgruppe Rhein Main und somit als Dienstleister hauptsächlich im Umfeld der Onlineangebote unserer Tageszeitungen im Bereich CMS und allen Randgebieten unterwegs. Im Kern der RMM sind wir neben Online Sales und Projektkoordination ein Team von fünf Kollegen, die sich um die Planung und Umsetzung neuer Projekte und Anforderungen an bestehende Systeme kümmern. Im Bereich der agilen Softwareentwicklung sind wir noch Rookies – wir beschäftigen uns seit Anfang des Jahres damit. Dabei machen wir nicht „Scrum by the Book“, weil dies als alleiniges Toolkit für die Vielzahl der von uns betreuten Applikationen nicht als tauglich erschien, sondern bewegen uns in einer gesunden Mischung der unserer Ansicht nach nützlichsten Komponenten aus Scrum und Kanban.

In den letzten Wochen hast Du in Deinem Blog „any-where“ über eine von Dir entwickelte Lösung berichtet, um einen Abgleich zwischen einem Offline-Taskboard und der elektronischen Aufgabenverwaltung mit trac herzustellen. Wie kamst Du auf die Idee und wie funktioniert Deine Lösung?

Hoffentlich hole ich jetzt nicht zu weit aus. Ich arbeite seit 2010 bei RMM und war bis Ende letzten Jahres in ein großes Projekt mit einem unserer spanischen Dienstleister als technischer Berater involviert. Das Projekt scheiterte leider. Wie ich nun weiß, aufgrund der vielen üblichen Fehler, die man machen kann: Falsche Anforderungsanalyse, fehlende Transparenz, das parallele Arbeiten an vielen Tasks und Komponenten, Terminfixierung statt Qualitätsfixierung, fehlende Prioritäten und der Plan eines Big Bang Releases. Erkannt wurde dies früh, aber leider nicht angegangen aufgrund der politischen Struktur des Unternehmens und des Projekts. Anfang des Jahres beschlossen wir, dass dies so nicht mehr passieren darf. Wir begannen, unsere Arbeitsweise hin zu mehr Agilität und Effizienz zu bewegen. Eine Entscheidung übrigens, die direkt aus dem Team heraus angestoßen wurde und einen wirklich spannenden Prozess folgen ließ, der eine merkliche Verbesserung unserer täglichen Organisation und vor allem der Transparenz aller Aufgaben und Projekte mit sich brachte. Ich will das gar nicht im Detail ausführen. Aber unter anderem hängt in unserem 4-Mann-Büro nun ein großes Taskboard, das über alle Projekte hinweg unsere Tasks erfasst und jeden Morgen in einem Daily Stand-up besprochen wird. Auf der Suche nach einem OpenSource-Tool für agile Entwicklung stieß ich auf Agilo als (recht) brauchbare Erweiterung für Trac. Dieses setzen wir nun ein und brauchten quasi sofort eine einfache Möglichkeit, das Offline-Medium Board mit dem Online-Medium Agilo zu verheiraten. Agilo und Trac bringen von Hause aus keine Unterstützung mit. Deshalb entwickelte ich ein kleines Java-Tool TracPrinter, welches aus einem Applet heraus das Drucken von Task-Cards erlaubt. Mit diesem schafften wir den Weg in die eine Richtung: Aus dem Intranet ans Board.

Nun kommt es bei uns oft vor, dass ein Ticket bearbeitet wurde, in „Done“ auf dem Board verschoben, aber in Agilo nicht aktualisiert wurde. Das ist ärgerlich, weil es neben dem Aufwand des nachträglichen Änderns in Agilo viele zu beantwortende Nachfragen gab, wenn die Tickets in Agilo kontrolliert wurden. Wir brauchten also einen einfachen Weg, Tickets in Agilo schnell schließen zu können. Da quasi jeder Zugang zu einem iPhone oder Android-Gerät mit WI-FI-Zugang zum Intranet hat, dachte ich, dass es das einfachste wäre, über das Smartphone eine Möglichkeit zu schaffen, Tickets in Agilo zu bearbeiten. Als einfachste Lösung schienen hier QR-Codes in Frage zu kommen: Somit wurde TracPrinter erweitert um eine Funktion, welche QR-Codes mit einem hinterlegten internen Link zu einem einfachen PHP-Script auf die Ticket-Karten schließt. Nach Scannen des QR-Codes öffnet der Browser dieses Script auf dem Server im Intranet. Derzeit schließt dieses wirklich nur „hart“ das Ticket. So haben wir erreicht, dass Tickets direkt nach Fertigstellung oder im Daily Stand-Up innerhalb von Sekunden geschlossen werden können.

Wie bewährt sich diese Lösung bei Euch im Praxis-Einsatz?
Die Gesamtlösung mit TracPrinter und der neuen QR-Code-Lösung unterstützt unsere Prozesse recht gut. Wie bei allen Dingen steht und fällt dies natürlich mit der Gewohnheit der User: Man muss natürlich dran denken, den TracPrinter zu nutzen, um ein Ticket, das man gerade erstellt hat, auch ans Board zu bekommen. Hier kommen wir öfter an den Punkt, dass ein Ticket zwar in Agilo ist, aber nicht am Task-Board hängt. Aber wir werden besser. Das korrekte Schließen des Tickets in Agilo wird im Daily Stand-Up mittlerweile abgefragt und im Zweifel direkt per Smartphone geschlossen. Hier haben wir wirklich einen Gewinn.

Welche weiteren Entwicklungspotenziale siehst Du für Deine Lösung?
Noch ist alles eine Sammlung loser Tools: Agilo hat seine eigene URL, der TracPrinter ist unter einer eigenen URL im Intranet erreichbar, ebenso das Script, welches Requests via QR-Codes entgegennimmt. Das klappt natürlich – geplant ist allerdings, alles zusammen in eine Erweiterung für Trac zu überführen, um alles an einer Stelle zu haben und den manuellen Schritt des Druckens von Karten direkt in die Erzeugung von Tickets zu integrieren. Darüber hinaus habe ich ja erwähnt, dass via QR-Code die Tickets hart geschlossen werden: Man kann noch nicht differenzieren, ob ein Ticket done oder invalid ist. Auch eine Schnittstelle zur Kommentarfunktion von Agilo existiert nicht. Da die Lösung aber gut angenommen wird, ist der Plan, ein mobiles Interface für Agilo zu schaffen, das es erlaubt, direkt alle Informationen über ein Ticket abzurufen und eine Möglichkeit zu schaffen, den verschiedenen „Schließmöglichkeiten“ in Agilo gerecht zu werden. Somit kann man noch mehr Zeit vor dem Board statt vor Agilo im Notebook verbringen 🙂 Das wird die Kommunikation über Tickets bestimmt weiter fördern.

Ein dänisches Scrum-Team von Vodafone hat vor einigen Monaten eine Lösung für den Abgleich zwischen JIRA und einem Offline-Taskboard mittels RFID-Technologie vorgestellt und dafür einige Aufmerksamkeit bekommen. Wie siehst Du die QR-Lösung im Vergleich zu einer RFID-Lösung? Was hat mehr Potenzial für die Zukunft?

Ja, die RFID-Lösung ist sehr fancy. Vor allem das automatische Einblenden des Burndown-Charts ist spektakulär und wirklich motivierend! Man sieht in Echtzeit den Effekt der Abarbeitung des eigenen Tickets. Tatsächlich war das Video, das ich im Dezember in Deinem Blog über diese Lösung gesehen habe, durchaus ein Impulsgeber für die Ideen, die hier mit Trac und QR-Codes nun umgesetzt sind. Das Problem, Onlinetools mit Offlinemedien zu synchronisieren, ist im Bereich der agilen Entwicklung sicher an vielen Stellen aktuell. Die Entscheidung, Papier zu nutzen und nicht auf einen „großen Touchscreen“ als digitales Board zurückzugreifen und alles direkt online abzubilden, wird ja bewusst getroffen. Nun sind QR-Codes sehr billig, RFID aber leider nicht. Das ist sicher auch einer der Gründe, weshalb wir auf QR-Codes setzen 🙂 Ich weiß ehrlich gesagt nicht, ob und welche Möglichkeiten es bereits mit QR-Codes für marktführende Tools wie Jira gibt. Ich kann mir aber durchaus vorstellen, dass dies eine tolle Unterstützung für viele Projekte sein kann. Uns nutzt es sehr – und solange nicht jeder die Möglichkeit hat, einen RFID-Scanner hinter sein Board zu hängen, ist dies sicher die effizientere Variante. Wenn das Vodafone-Modell aber in Serie geht, werde ich hier sicher vorschlagen, das zu kaufen 🙂

Wie siehst Du in Zukunft die Entwicklung zwischen elektronischem Taskmanagement und Taskboards in Teamräumen. Was für Möglichkeiten werden sich uns da in den nächsten 5-10 Jahren bieten?

Es dauert sicher nicht lang, bis der erste Anbieter ein elektronisches Hardware-Board für den kommerziellen Vertrieb bereitstellt. Auf welcher Technologie dies basiert, sei mal offen gelassen. Aber ich kann mir sehr gut vorstellen, dass es sehr interessante Lösungen geben wird, die in Richtung der Vodafone-Version gehen werden. Das Problem hier ist m.E. nicht unbedingt die technische Machbarkeit und die Kosten sondern vielmehr die Vielzahl der Produkte im Bereich „Taskmanagement“ und die Eigenarten der agilen Arbeit in Organisationen. Dem gerecht zu werden ist sicher eine Herausforderung für Hersteller. Am Ende ist ein einfaches Whiteboard doch schneller den persönlichen Bedingungen angepasst. Natürlich könnte ein Anbieter speziell für die Schnittstelle zu Jira (oder warum auch nicht Agilo/Trac?) ein solches Board herstellen. Ich bin selbst gespannt, was hier kommen wird. Ob RFID hier eine Lösung ist oder tatsächlich mit QR-Codes gearbeitet wird, die von einem Scanner direkt im Board verarbeitet werden können, ist sicher eine Frage der Kosten. Papier ist billiger als RFID. Aber wer weiß, wie sich das entwickelt.

Zum Schluss noch einmal zum Thema QR-Codes: Werden diese dauerhaft interessant und vielfältig im Einsatz sein oder stellen sie nur einen Übergang zu neuen Technologien und Lösungen dar?

Für mich ist unsere QR-Lösung tatsächlich der erste Fall, wo ich – jenseits von logistischen oder produktionstechnischen Anwendungsfällen – einen persönlichen professionellen Nutzen in QR-Codes sehe. Jetzt nutze ich sie täglich als Unterstützung meiner täglichen Arbeit 🙂 Im Consumerbereich sieht das anders aus: Für Endanwender sind QR-Codes ja schon heute bspw. für Ticketing oder Check-ins vielfältig im Gebrauch. Ihr Gebrauch ist einfach und kostengünstig. Wir arbeiten hier auch an Projekten, in denen QR-Codes im Bereich des Couponings und Location Based Services eine Rolle spielen werden. Somit werden sie uns noch eine Weile begleiten 🙂

Vielen Dank, Matthias!
Sehr gerne!

So sehen die Printouts mit QR-Code dann aus:
QR-Codes zur einfachen Aktualisierung eines Taskboards (Foto: Matthias Müller)

Blogartikel von Matthias Müller zu seinen Erweiterungen für trac:

Dir hat dieser Beitrag gefallen? Ich freue mich über einen Kommentar. Du kannst auch meinen RSS-Feed abonnieren oder mir auf Twitter folgen: @pherwarth.

„Scrum & Kanban im Agenturgeschäft“ – Treffen der Scrum Usergruppe Rhein-Main am 16. Juni

Das Juni-Treffen der Scrum Usergroup Rhein-Main findet in Wiesbaden statt. Am 16.06.2011 bieten Joachim Seibert und Paul Herwarth von Bittenfeld von der Internetagentur //SEIBERT/MEDIA Einblicke in die Arbeit mit Scrum und Kanban im Agenturgeschäft.

Neben den Erfahrungen bei der Einführung im Agenturgeschäft für ganz verschiedene Projektarten (die immer noch im Gange ist) werden Einblicke in die Teambüros und die Werkzeuge der Agentur gewährt.

Auch ein Blick in die Zukunft soll gewagt werden. U.a. steht in etwa einem halben Jahr ein Umzug an, mit dem sich Fragen zur optimalen Raumplanung für agile Teams stellen.

Das Ziel des Treffens ist ein praxisnaher, aktiver Dialog.

Ab 21 Uhr wird zum Socializing ins Orange am schönen Schiersteiner Hafen gewechselt.

Termin und Veranstaltungsort

Do, 16.06.2011, ab 19:30 Uhr

//SEIBERT/MEDIA GmbH
Rheingau Palais, Söhnleinstrasse 8
65201 Wiesbaden
Deutschland

Referenten des Abends

Joachim Seibert: Joachim ist Geschäftsführer und Leiter Technologies bei //SEIBERT/MEDIA. Im letzten Jahr hat er entscheidend die Entwicklung hin zu agilen Werten und Prinzipien im Unternehmen vorangetrieben.
Weitere Informationen über Joachim: http://seibert.biz/jseibert

Paul Herwarth von Bittenfeld: Paul leitet den Bereich Beteiligungen von //SEIBERT/MEDIA und ist in dieser Funktion auch als Product Owner für die Tochtergesellschaften TwentyFeet, Gartentechnik.com und naturkostaktiv tätig.
Weitere Informationen über Paul: http://seibert.biz/pherwarth

Anmeldung zum Juni Treffen der Scrum Usergruppe

25 Blogs zu Scrum und agiler Softwareentwicklung

Welche Blogs zu Scrum und agile Softwareentwicklung solltet ihr nicht verpassen? Vor einiger Zeit habe ich meine persönlichen Top 5 Scrum-Blogs vorgestellt. Agile Office fragte in einem Kommentar, welche weiteren Blogs ich zu dem Thema lese.
Nachfolgend daher eine umfangreichere Liste von 25 Blogs zu Scrum und agiler Softwareentwicklung:

  1. „Scrum Log“ von Jeff Sutherland: Der „Vater von Scrum“ schreibt seit 2002 über alles rund um Scrum, von „Dealing with Bugs in a Sprint“ bis zu „Hackathons – How it’s done at Facebook“
  2. „Telling It Like It Is“ von Ken Schwaber: Der Mitbegründer von Scrum und Gründer von Scrum.org schreibt regelmäßig über seine Sicht auf die Entwicklungen in der Scrum Community.
  3. ScrumAlliance Articles: Hier gibt es Artikel von vielen erfahrenen Scrum Trainern und Professionals.
  4. „bor!sgloger — leading Scrum with passion“ von Boris Gloger: Einer der bekanntesten Scrum-Trainer aus Deutschland versorgt uns regelmäßig mit aktuellen Tipps und Tricks rund um agile Softwareentwicklung.
  5. „All Things Product Owner“ von Roman Pichler: Der Scrumtrainer und mehrfache Buchautor schreibt regelmäßig und überzeugt durch tolle Anregungen, wie die zu einem Product Backlog Board.
  6. „Lean und Kanban“ von Arne Roock: Der Prokurist bei it-agile und Träger eines schwarzen Gürtels in Karate schreibt einen der wenigen deutschen Blogs über Kanban in der Softwareentwicklung.
  7. „Dayley Agile“ von Alan Dayley: Ein Softwareentwickler, der seit vielen Jahren auf agile Softwareentwicklung schwört und seine Erfahrungen mit uns teilt.
  8. Implementing Scrum von Michael Vizdos: Der Scrum-Trainer berichtet von seinen Erlebnissen, Tony Clark liefert ihm herausragende Illustrationen dazu. Sehr sehenswert.
  9. „inside-scrum“ von Jean-Pierre: Ein Anwenderbericht vom Start und der Durchführung eines Scrum-Projekts.
  10. Agile Product Design: Agile Softwareentwicklung betrachtet aus dem Blickwinkel des Product Designs, eine längere Zeit schon still, aber mit sehr interessanten Artikeln.
  11. Peter Beck: Scrum-Trainer von DasScrumTeam. Zuletzt leider etwas ruhig geworden.
  12. „scrum breakfast“: Die Selbstbeschreibung drückt es am besten aus: „Blog about Scrum: getting started, crisis project management and transforming into a lean organization.“
  13. ScrumEdge: Ein weiteres Scrum-Blog, das durch eine hohe Frequenz von guten Artikeln überzeugt.
  14. „Agile Product Owner“ von Jennifer: Die Eigenbeschreibung „Sharing the Art of Agile Product Ownership“ trifft es auf den Punkt. Zuletzt ist es in dem Blog leider eher ruhig geworden.
  15. ScrumCenter: Der Corporate Blog eines agilen Beratungsunternehmens. Viele Inhalte von Präsentationen werden behandelt, aber auch auf interessante Artikel verwiesen.
  16. Scrumology von David Bland: Entgegen dem Namen geht es nicht nur um Scrum, sondern auch um Kanban und „schlanke“ Softwareentwicklung. David teilt seine Erfahrungen aus der Praxis.
  17. Stefan Roock: Der Trainer für agile Softwareentwicklung berichtet über seine Erlebnisse und Erfahrungen aus seiner Beratungstätigkeit.
  18. The Agile Executive von Israel Gat: Dieser Blog beschäftigt sich mit dem Rollout von „Agile“ auf Unternehmensebene, also über einzelne Teams hinweg.
  19. The Agilista PM von Donna Reed: Mit Fachartikeln, Webinaren und Webcasts werden hier Aspekte des agilen Projektmanagements behandelt.
  20. Scaling software agility: Wie lässt sich agile Softwareentwicklung in großen Projekten einsetzen? Hier gibt es Antworten.
  21. PM-Blog von Stefan Hagen: Obwohl sein Blog nicht ausdrücklich auf agile und schlanke Vorgehensweisen fokussiert, ist ihm dieses Faible von Stefan anzumerken.
  22. „ScrumTools – agiles Projektmanagement“: Neben einer Liste von Scrum-Tools gibt es von Zeit zu Zeit Artikel im zugehörigen Blog.
  23. agileoffice: Agile, Lean und Scrum sind die Themen, mit denen sich dieses Blog beschäftigt.
  24. „Systems Thinking, Lean and Kanban“ von David Joyce: David teilt seine langjährigen Erfahrungen als Coach und Teammember und verweist regelmäßig auf spannende Artikel.
  25. „Lean Software Engineering“ von Corey Ladas und Bernie Thompson: Die beiden teilen ihre Erfahrungen aus Teams von u.a. Microsoft und IBM. Ihre Artikel bekommen hohe Aufmerksamkeit und sorgen regelmäßig für umfangreiche Diskussionen.
Dir hat dieser Beitrag gefallen? Ich freue mich über einen Kommentar. Du kannst auch meinen RSS-Feed abonnieren oder mir auf Twitter folgen: @pherwarth.
Foto: Von Rafa[EU]
%d Bloggern gefällt das: