Alle Beiträge von Markus Wissekal

Über Markus Wissekal

Markus ist, was man als agiles Taschenmesser beschreiben könnte: akkreditierter Kanban Trainer, Scrum Professional, Lego Serious Play Facilitator, systemischer Coach, Design Thinker, Lean Experte, Medizininformatik-Absolvent sowie Unternehmensberater. Diese spezielle Kombination aus Technik, Business und lösungsorientierten Denkansätzen wendet er seit über 10 Jahren in der Arbeit mit unterschiedlichen Unternehmensebenen an - egal, ob es dabei um den fokussierten Projektstart, die Effektivitätssteigerung agiler Teams, das Programm-Management im mehrstelligen Millionenbereich oder ein Sparring auf Augenhöhe mit der Geschäftsführung geht. Seit 2017 ist Markus Wissekal nun gemeinsam mit Stefan Kinigadner unter der Marke coach und coach GmbH unterwegs, um sowohl die Innovationskraft als auch die Produktivität der einzelnen Menschen, Teams und Organisationen in der DACH-Region zu stärken. Wenn Sie Interesse an einem Training in der DACH Region haben, oder Interesse daran wie Kanban, Scrum oder Lean in Ihrem Unternehmen funktionieren können, dann hinterlassen Sie mir doch eine Nachricht.

Scaling Agile & Lean – Spotify Squads, Tribes and Chapters

Allgemein, Management, News, Planning, Scale, , ,

Die Reihe „Scaling Agile & Lean“

Agile Methoden wie Scrum werden mittlerweile in den meisten Unternehmen eingesetzt, einige Studien gehen davon aus, dass 80% aller Unternehmen agile Prozesse einsetzen, konservativere Studien sprechen von etwas mehr als der Hälfte. In den meisten Fällen dürfte sich dies jedoch weiterhin auf den Einsatz von Scrum oder Kanban in Teilbereichen der Unternehmen, wenigen Teams oder Projekten beschränken.

Ansätze, um hinweg über viele Teams zu skalieren (Scaling Agile) fehlen häufig und werden für größere Unternehmen die auf Agilität setzen möchten immer wichtiger. Häufig scheitern Implementierungen von Scrum jedoch an dem fehlenden übergeordneten Koordinierungsbedarf, da der Fokus in den meisten Fällen zu sehr auf die Entwicklungs-Teams und weniger auf die Unternehmens- oder Portfolioebene gelegt wird. Besonder viele Reibungsverluste gibt es bei der Integration von agilen Organisationsteilen (z.B.: Entwicklung von neuen Systemen) und weiterhin eher traditionell organisierten Organisationsteilen (z.B.: Vertriebsorganisation, Abteilungen mit Fokus auf Wartung, Zulieferer).

Die Fragestellung, wie agile Methoden in größeren Unternehmen eingesetzt werden können, ist jedoch nicht neu. In der Reihe „Scaling Agile & Lean“ stellen wir einige der bekanntesten Frameworks und Methoden die hierbei Anwendung finden vor.

Scaled Agile @ Spotify im Detail

Einen sehr interessanten Ansatz für die Skalierung von agilen Teams verfolgt Spotify. Hier wurde auf über 30 Teams („Squads“) skaliert. Teams die in einem Kontext arbeiten, werden in sogenannten „Tribes“ gruppiert.  Der Kontextübergreifende Austausch geschieht durch die Etablierung von so genannten “Chapters”.

Diese Begrifflichkeiten mögen für einige gewöhnungsbedürftig sein aber sind sicherlich für viele Agilisten attraktiv, da diese häufig den klassischen Methodenwerken schon alleine wegen der vielfach missbrauchten Begrifflichkeiten ablehnend gegenüber stehen.

Liefereinheiten

Squad

Entspricht in etwa den üblichen agilen Teams, wobei kein spezifisches Vorgehen oder Framework wie beispielsweise Scrum oder Kanban vorgeschrieben ist. Es gibt einen Product Owner, der die Themen vorgibt und jemanden, der sich um das Team und die Einhaltung von Regeln kümmert (“Agile Coach”). Der “Agile Coach” gehört nicht ausschließlich zu einem Squad er muss aber für „seine“ Mitarbeiter verfügbar sein.

Scaling Agile @ Spotify
Scaling Agile @ Spotify

Scaling Agile & Lean – Spotify Squads, Tribes and Chapters weiterlesen →

A new new taskboard for product development

Artifact, Management, Planning, Teamspirit, Watch and see, ,

There are loads of blog posts covering topics on how to shape the perfect taskboard (Kanban/Scrumban/Scrum/Task-boards) for your agile team. My team tries to complete an ever changing project with less than twelve two-day sprints, which puts our regular board design to its limits. We tried to create a board that can actually accommodate our ever changing ideas (and solutions) and thereby created a completely different kind of taskboard.

This is how we did it:

Product Owner, UX experts and the development team sketched the components (and interactions, events, …) for a new feature onto a plain whiteboard and thereby drew the goal for the next iterations. By doing so the board even became part of the documentation as all UI elements are already displayed (and prioritized) as part of the daily work. This clearly increased the teams product focus and made the goal of the current super short iteration visible: Finish the component you are currently working on!

The current task for each developer is shown with his very own magnet. Our WIP-Limit at hand is one – so there is just one magnet per team member. Whenever a task (e.g. frontend-element) is finished the developer reviews it with another team member. If both agree, that it fulfills our definition of done (DoD) both just put a checkmark on it.
Things that are not sketchable on the board like profiling, backend-services or stylesheets have their bubbles outside the drawn userinterface.
As many other teams we also have technical dept. For bugs we have our very own fastlane bubble where bugs can be placed and the next free developer can start working on them.

On a board like this it is difficult to visualize the priority of work items. For that reason we scribbled the priority of the UI elements directly onto the front end elements. That leads to the drawback that one has to search the board when looking for the “next important” element, but this seems to be a small price to pay for such a taskboard.

By the way, since the task board has been designed and the elements have been visualized ,we were much more successful to identify further important improvements (to be addressed in the next 2 day iteration) while working on the elements.

At the moment we are very satisfied with the results we get – but we are still in the beginning of our project with only a few two-day sprints finished. We believe that there are still loads of opportunities to further improve the design of the taskboard and the way we are working with it.

Our “inspect and adapt” cycle has just started.

TaskBoards müssen nicht gleich aussehen

Allgemein, Artifact, Planning, Teamspirit, Watch and see, ,

Update: English version available.

Es gibt unzählige Artikel im Netz, wie man ideale Taskboards – (Kanban/Scrumban/Scrum-Boards)  für agile Teams erstellen kann. Mein Team versucht zur Zeit ein sich oftmals änderndes Projekt mit weniger als 12 Zwei-Tages Sprints umzusetzen.

Die Idee war nun, unser Taskboard den sich ändernden Umständen anzupassen und eine völlig andere Form für dieses Board zu finden.

Das Ergebnis erfüllt zur Zeit all unsere Anforderungen. Tasks (Frontend-Elemente) werden abgearbeitet (siehe Magneten der Entwickler) und können abgehakt werden, wenn sie unserer Definition of Done entsprechen. Dinge die nicht im skizzierten Userinterface ersichtlich sind (z.B. Profiling-Tasks, CSS-Änderungen,…) haben eine eigene Bubble in der die entsprechenden Teammitglieder kleben.

Altlasten in Form von maintainance oder Bugs werden als Postits ans Board geklebt oder anders dargestellt.

Taskboard 2.0

Da ein skizziertes Board schlecht mit Priorisierungen einher gehen kann, schrieben wir die entsprechende Priorität des UI-Elements einfach auch ans Board. Dies bedeutet zwar, dass man ein wenig länger suchen muss, um das nächst-wichtige Steuerelement zu finden, dies ist aber ein kleiner Preis den man für solch ein Taskboard zahlen muss.

Durch die spielerische Art, mit der die UI skizziert ist, wurden auch noch während des Arbeitens Änderungen eingebracht und gleich im nächsten Zwei-Tages-Sprint umgesetzt.

Bis jetzt mögen wir unser Board; aber wir sind ja auch erst im zweiten Sprint – was noch viel Raum für Veränderungen lässt. Wenn Ihr gute Ideen für uns habt, lasst es uns wissen. Frei nach dem Motto: „inspect and adapt“.

Die „Power-Week“ als Produktivitätsfaktor

Engineering, Management, Teamspirit

Nach einigen Diskussionen über die nicht änderbaren schlechten Schallschutzmaßnahmen in unserem alten Großraumbüro (Straßenlärm bei geöffneten Fenstern, Drucker die von dem ganzen Stockwerk genutzt wurden,…), und einem neuen Mitglied in unserem Entwicklerteam, entschieden wir uns dem Occupy-Movement zu folgen. Wir besetzten also einen Meetingraum (für eine volle Woche) und begannen dort  mit unserer „Power-Week“.

Regeln für die Power-WeekTony Schwartz‘ Artikel „The Magic of Doing One Thing at a Time“ bestärkte uns in dem Bestreben erstmal zu definieren wann „Ruhezeiten“ sind, und wie diese auszusehen hatten bzw. wann man für Störungen „zur Verfügung“ stehen wollte.

Wichtig war für gemeinsam im Team zu arbeiten, und damit schnell zu hervorragenden Ergebnissen zu gelangen.

Für die Power-Week hatten wir das perfekte Thema – ein technisches und grafisches redesign (JS-Framework, Usability, neue Steuerelemente) der Suchformulare unserer Seite. Um diese Aufgabe in einer Woche bewältigen zu können bestand das Team aus vier Entwicklern, einem UX-Designer und dem ProductOwner, der sich ebenfalls zu dieser Power-Week commitete.

Dienstags (8 Tage später) mussten die Suchformulare testbar sein, da schon Personen für den Usertest eingeladen waren.

Transport der HardwareMit diesen Bedingungen startete die Power-Week.
Montags um 8:00 versammelten wir uns dann im Großraumbüro und besprachen kurz das Vorgehen für den „Umzug“. Als ScrumMaster hatte ich einen Wagen besorgt, um Hardware (Monitore, Telefon, Switches udgl) und Software (Teammitglieder) in unsere neuen Räumlichkeiten transportieren zu können.

Meetingraum Genf - vorherMeetingraum Genf - nachherNachdem alles angeschlossen war und der ProductOwner die einzige Möglichkeit darstellte wie „die Welt“ mit dem Team kommunizieren konnte war eine „sichere“ Umgebung geschaffen.

Thomas bei der arbeit im Raum Genf Auch unser UX-ler fand im „neuen Büro“ seinen Platz und konnte das Team tatkräftig mit seinem Input zu den neuen Steuerelementen unterstützen.

Er stand somit jederzeit zur Verfügung, wenn es Fragen bezüglich der Usability oder des Designs gab, was kürzest mögliche Entscheidungswege bedeutete.

Ich bat unseren PO am Ende der Woche einen Kommentar für den Blog abzugeben, hier sind seine Worte:

„Im täglichen Doing ging es relativ gut von der Hand. Der Sprint war erfolgreich, ich kann die positiven Punkte nochmals stichpunktartig hervorheben:

  • Der größte Pluspunkt: eine ruhige Arbeitsatmosphäre, kein lautes
    Großraumbüro neben der Autobahn. Dadurch musste auch niemand einen Kopfhörer aufsetzen, um sich vor dem Lärm zu schützen, und so bekam jeder mit, was der andere tat und dachte
  • An spontanen Diskussionen/Fragestellungen konnten sich alle sofort beteiligen
  • Es gab ein Thema, nicht viele kleine, was positiv zur Motivation beitrug. Das know-how war im kompletten Team vorhanden, somit konnte auch jeder zum Erfolg beitragen
  • Dadurch, dass wir nur ein Thema bearbeitet haben, war es dann auch der Erfolg aller am Ende des Sprints“

Mit dem heutigen Tag sind die neuen Suchformulare auf unserer wichtigsten Seite (www.holidaycheck.de) verfügbar, nachdem sie die letzten Wochen für einen kleineren Teil unserer Nutzer auf der österreichischen Seite online gegangen waren.

Hier noch ein paar Screenshots der Formularelemente: