Simple Agile Tools

Just like many other people, the teams in my company are working from home since 4 months. We were quite used to this situation, because we’re pretty flexible when it comes to times and locations.

However, we also had to find tools to support us in our daily work. I personally tried many different online tools for estimations, retrospective meetings or other kinds of workshops with the people in my organization.

Continue reading “Simple Agile Tools”

Meetings draußen abhalten

Deichtor Bremen

Es gibt Tage, an denen mein Kalender von morgens bis abends zugekleistert ist mit Terminen. Das sind die Tage, an denen mein Schreibtisch im Büro keinen anderen Zweck hat als Staub zu fangen, während ich mit meinem Notebook unterm Arm von Besprechungsraum zu Besprechungsraum laufe. Wir haben schöne Besprechungsräume in unterschiedlichen Größen und Ausstattungen. Dennoch wurde mir vor rund zwei Jahren die Luft dort zu dick – es engte mich förmlich ein, Gespräche mit Menschen in den immer gleichen gewohnten Räumen zu führen. Mir fehlte die Inspiration, die Bewegung, die Dynamik und das “Ausbrechen” aus den altbekannten vier Wänden.

Continue reading “Meetings draußen abhalten”

Jetzt hör endlich mal zu!

Blubb war ja klar

Die wichtigste Voraussetzung für den Aufbau von wirkungsvollen Beziehungen und somit eine Grundlage für Führung ist: Zuhören. Richtiges Zuhören. Zu oft hören wir zu, um eine Antwort zu geben. Nicht, um zu verstehen. In diesem Artikel beschreibe ich zwei für mich hilfreiche Modelle, die es ermöglichen, Zuhören zu analysieren und zu üben und habe im Anschluss noch ein paar Tipps parat für besseres Zuhören.

Continue reading “Jetzt hör endlich mal zu!”

A long and winding road.

Heute möchte ich mal wieder kurz über unseren Weg hin zu mehr Effizienz und Transparenz beschreiben, den wir als Softwareentwicklungsteam seit einigen Monaten beschreiten. Der Titel des Beitrags klingt vielleicht unterschwellig viel negativer, als ich es meine. Aber er drückt doch gut aus, was gerade passiert: Wir befinden uns auf einer langen Straße, die, um es noch bildlicher auszudrücken, am Anfang sehr holprig und ohne Beschilderung war und nun immerhin schon zu einer stattlichen Bundesstraße ausgebaut wurde.

Nachdem wir Anfang 2011 begannen, unsere Entwicklungsarbeit in User Stories und Tasks toolgestützt zu organisieren, konnten wir schon einen enormen Fortschritt erreichen: Durch unsere Daily Stand-up Meetings  sorgten wir für eine große Transparenz der Dinge, die gerade passieren. Sei es in Entwicklungsprojekten oder in den vielen Wartungsprojekten, die wir in unserer Firma betreuen. Insbesondere finde ich die Wandlung in der Kommunikation spannend: In einer Atmosphäre ohne Finger-Pointing steht jeder für die Dinge gerade, die er erfolgreich erledigt, gibt aber auch einen ehrlichen Status über die Dinge, die nicht gut laufen und wo er Hilfe benötigt. Letzteres ist heute noch manchmal nicht so leicht, wie mir auffällt. Aber wir werden besser. Im großen und ganzen entsteht eine immer offenere Atmosphäre, was sich zwangsläufig auf die Produktivität aller niederschlägt.

Nach einer Scrum-Basis-Schulung später im Jahr durch it-agile führten wir nun auch regelmäßige Plannings, Reviews und Retrospektiven ein. Ein großer Schritt! Und wieder ist hier die Wandlung der Kommunikation das eigentlich spannende: das regelmäßige Erarbeiten von guten wie schlechten Aspekten im vorangegangenen Sprint sorgt in der Retrospektive für ein immer offeneres Miteinander des gesamten Teams, inkl. Product Owner und Scrum Master (auch, wenn wir diese Rollen bisher noch gar nicht so etabliert haben, wie sie das Scrum Buch definiert). Der stetige Drang, den Entwicklungsprozess zu verbessern durch ein “optimiertes” Miteinander, wird erst durch die Retrospektive in Gang gesetzt. Nicht zuletzt ist gerade dieses Meeting, aus welchem man mit konkreten Verbesserungsvorschlägen ins nächste Sprint Planning geht, höchst motivierend – committet man sich doch auf Schritte, die man selbst als verbesserungswürdig definiert hat.

Aber auch unsere gesamte Entwicklungsplanung verbessert sich stetig: Insebesondere werden durch die Plannings und durch das Committment auf ein Gespräch über jede User Story die Produkte besser: War es bisher so, dass neue Features bis ins (vermeidlich) letzte Detail in großen Excel-Listen im stillen Kämmerlein erstellt wurden und das “Design” der Software in der Umklammerung einzelner lag, bewegen wir uns heute immer mehr in einer Atmosphäre, in der die Intelligenz des gesamten Teams genutzt wird: Features werden mit dem Product Owner gemeinsam diskutiert und die Anforderungen und Akzeptanzkriterien zusammengetragen. Vor der Bearbeitung einer jeden User Story wird das Gespräch mit dem Product Owner gesucht und die Details der Anforderung besprochen. Eine bemerkenswerte Änderung hin zu mehr Kommunikation, weniger Dokumenten-Overhead und größerer Qualität durch Klarheit der Anforderungen.

All diese Dinge gehen einher mit einer Veränderung der Coding-Methodik und allgemeinen Zeitorganisation: Peer-Reviews wurden Pflicht, wo immer es geht wird Pair Programming durchgeführt. Darüber hinaus blockt sich das Team als ganzes die ersten vier Stunden eines Tages für die Projektarbeit und wird hier nicht unterbrochen durch Anfragen aus Wartungsprojekten oder sonstigem Tagesgeschäft. Wenn also nicht gerade der Webserver brennt, hat das Team nun Zeit, den halben Tag ungestört am Projekt zu arbeiten. Alle weiteren Abteilungen akzeptieren dies voll und kommen mit ihren Anfragen außerhalb dieser Zeiten – also vor 9 Uhr oder nach 13h. Das sorgt für eine viel stärkere Fokussierung auf die Projektarbeit.

Alles in allem machen wir uns also immer besser. Es macht Spaß, zu erleben, wie man gemeinsam die Atmosphäre, in der man arbeitet, verändern, die Qualität verbessern und die Produktivität steigern kann. Die am Anfang dieses Posts angesprochene Straße hat nun doch eine recht deutliche Beschilderung und erfährt einen stetigen Ausbau. Die Schulung zum Certified Scrum Master steht auch noch an, dem Product Owner “blüht” auch eine offzielle Schulung und andere Abteilungen im Haus zeigen immer mehr Interesse an dem, was wir tun: immer wieder stehen Kollegen interessiert am Board in unserem Büro oder auf dem Flur, in welchem eine Übersicht über alle Projekte hängt, die derzeit bei uns bearbeitet werden. Alles in allem wird dies eine Erfolgsgeschichte sein, wenn sie fertig ist. Aber wahrscheinlich ist man das ja nie 🙂

A book about Radical Management.

As we started to do Scrum a couple of months ago on a project which was about to fail (and sadly did fail, but due to other reasons…), I came across the fact that there is huge potential to change the way we do things not just in project work but in our general daily work. At my company, we work in a great environment with really high-potential team members and a good social atmosphere. We are a small Online-Media & IT department under the roof of a medium sized newspaper publishing company. But even though we are less than 20 people, inert knowledge, intransparent descisions, unclear communication to stakeholders and a lack of knowledge about “who does what and what needs to be done” seem to result in a a re-active and dissatisfying way of work rather than a creative way of getting things done.  So, I started to read blog articles and books about self-managed teams and agile development.

One book which in a particular way drawed my attention is Stephen Denning’s “The Leader’s Guide to Radical Management”. I am not a manager – as a software engineer I am part of a development team. Nevertheless, this book opened my eyes to what it really is that slows down development and maybe makes people unhappy about work in general – it is often a lack of transparency and responsibility to decide what is to be done in what time and what circumstances. Based on Dennings experience and talks to various managers across multible sectors in several countries, this is due to the fact that companies in the 21st century are still being managed in a traditional and unflexible 20th century way which major goal is rather delighting a client by providing quality services than making money and managing strictly top-down come whatever. Denning uses many stories and case studies to describe ways to achieve the goal of self-managed teams, establishing successful agile development and how to have an atmosphere of high performing work. This shall lead to better quality work and services, delighted clients and last but not least a happy work environment.

Even though I as a developer am not in the position to change things in a wide way across my company, this book gave me a lot of interesting thoughts and valuable information to change things in my surroundings – I’m really looking forward to start changing things in my office by “spreading the word” and trying to get people on board to move forward to a better organised, self-managed way to work. We already started by talking about it, establishing tools to centralise documentation and knowledge and thinking about better ways to handle incoming work in a transparent and productive way. There’s a lot you can do – Scrum is one method, Kanban another but this is all based on an uncompromising transparency, the will to enhance productivity or courage to admit failure and asking for help, which surely are some principles which really need to be learned from scratch – for both: “workers” and managers.

I really enjoyed reading the book and recommend it to everyone who wants to change the way things are done. For both – managers and workers – this book offers great opportunities to start changing things for better. Go and read 🙂