Über Markus Wissekal

Markus Wissekal ist seit 15 Jahren in der IT-Branche tätig. Im Jahr 2008 entwickelte er eine tiefe Begeisterung für agile Prinzipien und Methoden wie Scrum, Kanban und vielen Lean-Ansätzen. Ab 1.8.2015 ist Markus als Akkreditierter Kanban Trainer, agiler Coach und LegoSeriousPlay Facilitator verfügbar. 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.

becoming self employed – 12 questions that keep you from it and how I answered them

This week, after ten years of being an employee, I’ve started my new career as an independent agile coach and kanban trainer. While I feel way more motivated and super positive we all know our weaker self. These are the questions I had to answer “it”.
(It is known, that our weaker self starts questions with a BUT and oftentimes ends them with a ! instead of a ?)

But Markus, think about the safety you had with your previous employer!
A quote from “the matrix” comes to mind: „try to realize the truth! there is no spoon“ – the same is true for job security. In case of a consultancy, if you’re not „sold“ to a customer, there is a limited amount of undesirable jobs you can do – not more, and not less. You have to see the fact, that you are employed to create value for your employer. As soon as you’re not doing that, you’re out.

But Markus, you won’t get paid when you’re ill!
Let’s boil it down to money then.. how many days per year don’t you have a cold? The amount of money you make on these days hopefully far exceeded your sick leave.

But Markus, what if you get too many customers and just can’t handle all of them?
Well, the good thing in the agile (and most other) communities is, that you can always get help if you choose to ask for it. If indeed, you have too much on your plate, ask a fellow peer if she wants to help out or knows other coaches, facilitators or trainers that are looking for contracts at the moment.

You might even find the perfect fit for a customer you could only halfheartedly help.

But Markus, what if your customer doesn’t pay you?
Same thing as with every other aspects of your life. It is wise to have a legal costs insurance.

But Markus, nobody will pay for your education/trainings!
You are right, weaker self. There is no boss interested in my education.
And there shouldn’t be. Nobody should be more interested in my personal development than myself! It helps to set aside some (or a lot of) money to pay for the trainings I (or my fellow peers) deem useful for me.
A good friend of mine has set a minimum of 10.000eur/year for his own advancement. He knows that knowledge – and the application of it – distinguishes him from the competition.

I will set aside a similar sum per year for sharpening my mind. Maybe 10% of my income?

But Markus, you as a one man show don’t scale!
Indeed. If I wanted to „scale“, I would take a closer look at companies like crisp, oose, it-agile or kegon. These companies chose to reinvent themselves, thereby creating happier employees and also happier customers.

But Markus, what if your customers are abroad/want you to travel?
Then, my dear weaker self, it is totally up to me, if that customer fits into my current style of living.

But Markus, how can you survive in a market so full of amazing agile coaches?
Most colleagues of mine have their unique selling point. The same is true for me.
If you want to know more about it, just klick here.
For my german speaking readers: There is an amazing 3min youtube video called “Das Pinguin Prinzip”. Take a look if you understand some german.

But Markus, how can you possibly manage your time without a boss, a bonus or goals to drive you?
Weaker self, we both have read “Drive” by Daniel Pink. You should know how little I think of monetary bonuses or performance appraisals for skillful or creative work.

But Markus, are you not scared you won’t find a “real” Job, if you ever decided to go “corporate” again?
You are right, some companies don’t accept CV’s of candidates that have been self-employed. The question you should ask yourself is:

  • Why would an employer not want candidates with an entrepreneurial spirit?
  • Would you want to work for a company like that?

I will combine the next four questions…
But Markus, how will you acquire new clients if you’re working all the time?
But Markus, what if you can’t work with big firms for legal reasons? (payrolling)
But Markus, what about your retirement plans?
But Markus, won’t you hate doing tax reports and all the other back office stuff?
Now we’re looking at the „real“ problems, that need real solutions.
At the moment, I’m handling my customers through a supplier/provider.
What does that mean? I’m basically employed by them and get my hourly rates on the 10th of the next month with some percentage for back office, contract creation, retirement plans, taxes and so on.
I will invest more time at conferences, meetups and so on to reinvent myself as a „product“ and find new customers. Already some of my previous customers are helping me to spread the word, which I’m very thankful for.

But Markus, is it really worth the trouble?
I can only speak from the experience I got from the last three days.
So far my answer is: „Yes, yes, yes! I should have done it earlier.“

I’d love to hear read your comments on being self employed, or why you think it is a bad idea after all!

Eine bessere Version des Scrum Flow DiagrammsA better Version of the Scrum Flow diagram

Da ich morgen einen Workshop zum Thema Scrum und JiraAgile halte, habe ich nach bekannten Bildern des Scrum-Flow gesucht, um einen „Roten Faden“ duch den Workshop (Tabs: Plan, Work und Report) zu ziehen. Leider empfinde ich die existierenden Versionen des Scrum Flow Diagramms als unzureichend, da sie die Arbeit der Product Owner bestenfalls als „Sortierer“ von Listen darstellt.

Ich begann mit dem klassichen Flow um nach der dritten Iteration eine Skizze eines besseren Flow’s zu erhalten.


Das Ergebnis war anders als ich es mir zu Beginn vorgestellt hatte, aber die Darstellung der Arbeit des Product Owner (und seines PO-Staff) fand ich eben so gut, wie die Möglichkeit einige Artefakte und Zeremonien darzustellen. Weiter Aufgaben eines Product Owner (z.B. Abstimmung der Stories im skalierten Umfeld) können einfach hinzugefügt werden.
Die Zeichnung geht auch wunderbar mit Marty Cagan’s Dual-Track-Scrum einher.


Wenn Ihr Ideen habt, wie ich diese Zeichnung weiter verbessern kann, oder wenn Ihr mehr darüber erfahren wollt, wie man Jira mit Scrum vereint, dann kommentiert diesen Beitrag oder schreibt mir persönlich.

The click here to open the english version of this post.

Ihr könnt dieses Bild frei für Trainings oder Workshops benutzen, solange ich als Urheber genannt werde ;-)As I’ll be holding a workshop about the best way to use JiraAgile with Scrum, I planned to show the „standard“ Scrum Flow Chart to explain the three JiraAgile-Tabs (Plan, Work and Report). What I found missing in all of the existing Diagrams is the visualizations of the Product Owners‚ work. One could believe their sole purpose is sorting lists.

I started with a sketch of the regular flow and continued to iterate until I came to the bigger painting.

my version of the Scrum Flow Chart

The Result was a different kind of diagram than I had in mind at the start, taking the PO (and his staff) into account, while explaining some of the Ceremonies and Artifacts of a Sprint along the way. You could easily adapt it for a scaled Environment.
This „piece of art“ also corresponds quite nicely with Marty Cagans‘ Dual-Track-Scrum.

My final version of the Scrum Flow Chart

If you have any Ideas on how to improve this Scrum Flow Diagram, or want to know more about the art of using Jira with Scrum leave a comment below or contact me directly.

You can use this drawing freely for your trainings of workshops as long as you acknowledge me as the author ;-)

ScrumMasters – The Good, the Bad and the UglyScrumMasters – The Good, the Bad and the Ugly


Ende Oktober hatte ich die Freude beim Google Developer Fest zu sprechen. Da die meisten Teilnehmer Entwickler sind, hatte ich meine Session speziell für Teams entworfen: „ScrumMasters – The Good, the Bad and the Ugly“

https://www.youtube.com/watch?v=f_3q1m6pJ_8I had the pleasure to speak at the Google Developer Fest in late october. As most participants were developers – I wrote a session just for them: „ScrumMasters – The Good, the Bad and the Ugly“


Scaling Agile & Lean – Spotify Squads, Tribes and Chapters

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.



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

A new new taskboard for product development

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

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


Diese Galerie enthält 12 Fotos.

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 … Weiterlesen