Most of you may know these effects and biases. This is not about letting you know, but giving you a checklist, to run it every time and remind you of the obious. Enjoy!

Are you affected by Dunning–Kruger effect?

Basically it burns down to Dunnings cite:

„If you’re incompetent, you can’t know you’re incompetent. […] The skills you need to produce a right answer are exactly the skills you need to recognize what a right answer is.“

So get yourself or the affected person around a coaching / mentoring on the issue. An educated opinion from outside could maybe open the field for discussion. Don’t stick to your own opinion there. Or to the opinion, that the other person has to „get it“, because it’s so simple.

Are you falling for Confirmation bias?


Confirmation bias, also called confirmatory bias or myside bias,[Note 1] is the tendency to search for, interpret, favor, and recall information in a way that confirms one’s preexisting beliefs or hypotheses. […] People display this bias when they gather or remember information selectively, or when they interpret it in a biased way. The effect is stronger for emotionally charged issues and for deeply entrenched beliefs.

So let somebody play the devil’s advocate. Or support the one’s who are showing constructive disagreement. Because diversity matters and hinders you to just follow the lemmings.

Are you overconfident?

Highly related to the Confirmation bias, though.


[…]in a spelling task, subjects were correct about 80% of the time, whereas they claimed to be 100% certain.[3] Put another way, the error rate was 20% when subjects expected it to be 0%. In a series where subjects made true-or-false responses to general knowledge statements, they were overconfident at all levels. When they were 100% certain of their answer to a question, they were wrong 20% of the time.

See also: Pareto principle

So estimate your optimistic, realistic and pessimistic view and ALWAYS take the pessimistic. Because you most probably fall for this bias. Esp. in teams.

Did you looked for the real problem?

Are you working on the root or just on the or some causes of a problem? Do you love the problem or just your solution? Most times it’s much more simple to work on causes, but in-effictive.

So, what?

  • Five why’s

Did you start with why?

Watch my namesake at TED

I have a dream! instead of I have a plan!

In my teams I found it useful to have a Confluence page available where you can easily get the team’s JIRA-issue-health. I have computed and commented the following JIRA Query Language Statements (JQL) for you. Pls. find my last article worth reading before.

If you are experienced with working with JIRA and Confluence you maybe skip the Groundworks part and take the JQLs as an inspiration.


Get a new Confluence page and start by adding the JIRA Macro to it. Just start typing {ji… and select JIRA.
After that you can paste the JQL (see below), edit the project and hit the magnifier to see a first result appearing. If not, check your JQL again.

If in doubt, you perhaps should copy it to JIRA and carve it there until it’s fine and re-apply it to the macro dialog in Confluence. Upside on JIRA’s Search for Issues — Advanced GUI is autocompletion and instant JQL checking.

If you thing standard set of fields to display is not suitable for your JQL, just edit them by clicking Display options at the bottom of the Macro dialog. (For instance it’s not very useful to have the description show for issues which have none 😉


No description

So simple, that you wouldn’t think of, but this actually discovered some unloved ones.

project = WHATEVER and status not in (Recorded, Open, OtherOpenStates) and resolutiondate is EMPTY and description is EMPTY

Perhaps you should exclude sub-tasks with:

and issuetype not in subTaskIssueTypes()

No update in 30 days

Everything which is somehow in progress, but was not touched for over 30 days. Adjust it to your own time frames.

project = WHATEVER and status not in (Recorded, “Not Started”, Failed) and resolutiondate is EMPTY and updatedDate <= startOfDay(-30d)

In current sprint and was in sprint(s) before

For Scrum teams. You can easily get the ones which where too big or to difficult. Nice table to talk about meta stuff in Retro. Here it’s useful to add the field Sprint via Display options in Macro dialog.

project = WHATEVER and Sprint in openSprints() and Sprint in closedSprints() and resolution is EMPTY

Due date imminent

Every issue where the due date is will end before end of the current week and which is not closed.

project = WHATEVER and duedate <= endOfWeek() and resolution is EMPTY ORDER BY duedate ASC

Punch line is

Most people know JIRA, a few know how to use it for their own measurements. I discovered from my teams that they’re using it more by having Confluence pages with handpicked and relevant filtered issues. Maybe you find it as useful as me.

Please leave me a comment, if

  • it’s useful
  • if you have an annotation
  • you want to share your health check JQLs with us!

As you were reading Albina Popova’s articles [1, 2 & 3] about #NoEstimates you might have wonder how you would do some kind of measuring without story points and explicit estimation. These JIRA and Confluence shorthands may help you:


First of all, please open your Board Configuration by clicking “Board” in upper right corner and then “Configure”. Navigate to the “Estimation” Tab on the left column. Here select “Issue Count”.

Burndown Chart


This has the impact, that “Issue Count” is default option for Burndown-Charts from now on. And this is as helpful as Story Point Burndowns were. They’re a pretty good indicator, how your sprint is working out. But: please underscore indicator! It’s only your breakpoint to ask the team, it’s far from an precise evidence.

Velocity Chart

Without the config tweak above mentioned your Velocity Chart was pretty useless without using story points. Instead of Burndown Chart where you can choose “Issue Count” from dropdown, here at Velocity this is not possible. Now you have a quick view on how much issues your team has committed and completed in the last few sprints.

Before I personally figured this out, my hack was a JQL I fired every sprint and added a row in a Confluence table and visualized it via Confluence’s Chart-Macro.


JIRA-Chart macro

This is also available in JIRA, but I personally find it more useful in a Confluence status page, so POs and Team visits and sees it more often. I really like the JIRA-Chart macro, esp. the “Created vs. Resolved” variant. If you configure it like this, you can get some information out of this (esp. interesting for Kanban-Teams, where Burndowns and Velocity Charts don’t apply).

What you get out of this, these two examples of two teams might show you.

On the left a Kanban team which is in a good flow (which you can see form the negative created vs. resolved ratio) and on the right a Scrum team which is at the beginning of a project and not so good with focus and finish. Created vs. resolved ratio is positive and increasing.


This is not a special hint for NoEstimate measurement stuff in Confluence, but a very helpful with visualizing data in Confluence in general, I sometimes use to plot some numbers in graphs. The Chart-Macro is definitely no low hanging fruit to swallow, learning curve is like using LaTeX… But as I struggled in the beginning, I for now don’t want to miss this macro by now.

So, if you figure out some other numbers via JIRA, Excel or so, you might just throw them in Confluence and show them.


I hope these few hints did the trick for you, if they were new to you. If you have questions, comments or other interesting stuff regarding this topic, pls. drop me a note below.
Thanks for reading. ?

I just attended the Lean Kanban Central Europe 2016 (#LKCE16) here in Hamburg, which was held on 8th — 9th of November.

Disclaimer: This is my personal review and influenced by the sessions I’ve attended. For others this might not copy or apply as well.


First of all: For me the form won over content. It was simply terrible cold. Wait, why was it cold? Because someone picked a nice designed, small restaurant like place for over 200 people (guess) and pimped it with two tents outside. Heaters were installed but not able to fight the cold, which was quite unusual for Hamburg, but still it is autumn and close to winter and we’re not talking about mediterran weather here.

At some time on the first day they provided blankets and even socks to fight the cold. List of cons would add up a lot, to make it simple: This conference was not easily usable. If it would be a website which I should visit and read (and had not pay for) I would simply close it.

Signal to noise ratio was really low.


Keynotes were held by David Anderson, Niklas Modig and Julian Birkinshawand had some interesting points.

Anderson has talked over Proto-Kanban (Slideshare), which in his mind is normal Kanban, with low maturity levels. High maturity levels would include pull across entire chain and scale, no backlog grooming and Risk Management / Hedging.

What I understood from this is: For having Kanban implemented you have to talk, you have to think and you have to really nail down the important and ugly questions. For me it was always like this. One of my most used sentences during Kanban sessions was:

Intelligence is not built in the board, (hopefully) it is staying infront of it.

Part I of Modig’s speech was quite the one you can watch here on TED:

My takeaways:

Think Flow Efficiency, not Resource Efficiency.

Part II: Have a look at Jidoka.

1. Detect the abnormality.
2. Stop.
3. Fix or correct the immediate condition.
4. Investigate the root cause and install a countermeasure.

Takeaway from Birkinshaw’s speech:

Too much information creates a deficit of attention

His main topic was Adhocracy and his new upcoming book.


I was really happy being able to hear Marcus Hammarberg’s talk about his Kanban approach in helping a Indonisian hospital. I love such stories, because in the end all of our fance method stuff boils down to:

  1. Keep it simple
  2. Iterate on problem solving
  3. Have personal connection and impact
  4. We are all humans, with human communication biases and needs


For me the Lean Coffee session was very cosy and valuable. I for now think more like attending a Unconference or Open Space next time soon. 🙂

…in the same instand you have finished reading this article

Yes we are agile. We are doing the right things and we are doing the things right. And all that stuff. It is great to work in a real agile surrounding. It is fun, it is productive and effective. But then, when the year is over, tax men come along and say something like:

“Your profit is this high? You have to pay taxes this high!”

And perhaps now your values, your fun and your effectiveness go overboard like a reuse in a storm at Bering Sea. Old management overtakes, because “agile didn’t work”. Now you’re not longer captain on the ship.

But wait, how come?

This is the point I started thinking about just a few months ago and am still so shocked, I never thought that way or asked further questions. Perhaps you understand me after this — hopefully short and informative — article.


This is finance guy speech and vocabulary, but you have to know this.

  • Capitalizable Expenses
    Capital expenditure or capital expense (“capex”) is an expense where the benefit continues over a long period, rather than being exhausted in a short period. Such expenditure is of a non-recurring nature and results in acquisition of permanent assets.
  • Operational Expenses
    (opex or just expenses) is an ongoing cost for running a product, business, or system.
  • Intangible Assets
    An intangible asset is an asset that lacks physical substance (unlike physical assets such as machinery, software and buildings) and usually is very hard to evaluate. It includes patents, copyrights, franchises, goodwill, trademarks, trade names, the general interpretation also includes software and other intangible computer based assets.

In Practice: Heating up the room

In finance they are talking about two ways to spend money to heat a room:

  • Either you burn it. It gets warm, money is gone, no mid/long term value created.
  • Or you buy a oven and fuel. It gets warm, more money is gone, but you’ve created long term value, which you could show to your landlord (tax office) and probably get discount on rent (taxes).

Finance guys part between Operational Expenses (opex aka burn money) and Capitalizable Expenses (capex, Buy oven and fuel). The more capex you can track, describe and proof in front of a financial auditor, the more you are able to spread tax savings over years. Because you have added value in terms of intangible assets to the company.

Burning expenses the very first year (opex) may lead to the situation that your taxes are low the first year but go sky-rocketing the following years. Capex will spread the tax savings over more than one year so you don’t run in oscillating budget and following effects. And if you do it right with more than one product, you may end up with tax savings.

Describe, Slice, Track & Report

You see? You should care about project and ticket descriptions, slicing tickets the right way (research, development, maintenance), (maybe) time track and report it understandable. Then your company is no longer only feeling effective but proofing it year over year via spread tax savings.

This is so simple, when you know the reason and the tools upfront, but difficult in retrospective. So, please, start speaking to your CFO, finance or controlling staff how to improve your way of dealing with capitalization. It does help them in the first place, but on the long run it will support you as a Agile Coach, Scrum Master or Product Owner.

You will get more support you need, because not only you, but the finance staff sees the value you are delivering to the company. You are now no longer opex which is the first ballast to get rid off in a storm.

And beyond

I hope I just blew you out of your comfort zone into start reading, asking and talking about capex. Find one of the following links interesting and worth reading:


Get-Kanban bei der #lwipcgn

Das GET-Kanban-Spiel im Einsatz bei der #lwipcgn im CoWoCo in der Bottmühle in Köln.

Neulich habe ich das Buch „… und mittags geh ich heim“ von Detlef Lohmann gelesen und bin sehr begeistert. Ich habe lange nicht mehr ein so schön geschriebenes Fachbuch gelesen. Ich glaube das letzte war „Der Termin“ von Tom DeMarco.

… und mittags geh ich heim

Detlef Lohmann beschreibt seinen Alltag als Angestellter, frisch gebackener Unternehmer und alter Hase. Angefangen hat er bei einem schwäbischen Automobilhersteller, den er als ziemlichen Tanker beschreibt. Riesig, großer Wendekreis und langer Bremsweg. Er wollte aber mehr und entschloss sich zu dem Schritt selber Unternehmer zu werden. Und das ist er durch und durch.

Jede Seite in dem Buch handelt konsequent von der unternehmerischen Sicht auf eine Firma, auf die Unternehmung. Er verliert nie den Fokus dessen, was er gerade leitet und gibt dies in Form von Werten weiter. Wertebasierte Unternehmensführung, nicht in der Theorie, sondern in vielen kleinen Beispielen erklärt und hergeleitet.

Er versteht es mit seinen Prinzipien und Methoden sein Unternehmensschiff aufzuteilen und in viele kleine Schiffe aufzuteilen, die ab dann als Schwarm agieren. Klein, schnell, wendig und – JA! – agil auf Windänderung (a.k.a. veränderte Marktsituation, Kundenwünsche etc.) reagieren. Wenn Du Menschen sagen hörst: „Agil funktioniert bei uns nicht!“ oder „Das kann ja gar nicht gehen!“, dann empfehle ich dieses Buch.

Denn so ruhig das Buch geschrieben ist, so nachhaltig ist die Kraft und Inspiration die von ihm ausgeht. Ich habe lange überlegt, ob und wie ich ein Zitat, dass kurz und aussagekräftig ist hier schreiben kann. Denn meist entwickeln sich die Geschichten langsam und schließen mit einer kurzen Pointe ab, so dass es wenn dann sehr lange Passagen wären. Eine habe ich allerdings doch gefunden, die meiner Meinung nach in der Kürze das Buch wiedergeben kann.

Heute spaziere ich mindestens zweimal am Tag durch die Cafeteria und – schönes Wetter vorausgesetzt – auf die Terrasse. Immer treffe ich dort Menschen im Gespräch an, die produktiv arbeiten und gemeinsam Neues aushecken. Nie bekomme ich das Gefühl, dass hier über Gebühr Pause gemacht wird, im Gegenteil: Ich glaube, dass in der Cafeteria und auf der Terrasse wohl am effektivsten in der ganzen Firma gearbeitet wird. Kopfarbeit, neue Lösungen ausdenken und kluge Entscheidungen herbeiführen braucht eben Raum, Zeit und eine entspannte Atmosphäre – und keine Meetings.

S. 115, … und mittags geh ich heim, Detlef Lohmann, 2012

Nach meinem letzten Beitrag könnte sich der interessierte Leser fragen: „Wenn Scrum und Kanban also nur Methoden sind und nicht gleichbedeutend mit agil, was ist denn dann agil?“

Tja, was ist agil? Die Antwort ist einfach und schwer.

Es ist einfach zu sagen: Agil ist, wer nach den agilen Werten handelt. Die sind im Originallaut (hier in deutsch):

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

Agile Manifesto

Es ist schwer zu sagen, ob, wie und woran Du erkennen kannst, dass jemand oder Du selber nach den agilen Werten handel(s)t. Denn das ist das Problem mit Werten: Sie sind schwer bis gar nicht messbar.

Daher die Methoden

Diese einfache, aber simple Erkenntnis zeigt auch, warum die meisten Coaches Methoden lehren und vor allem verkaufen. Warum es einen Scrum Master gibt und keinen Agile Master. Methoden lassen sich besser verkaufen. Über Methoden lassen sich Bücher schreiben. Methoden können zertifiziert werden.

Auch ich merke gerade beim Schreiben, dass ich innerhalb dieses Artikels nur einen Grundstein legen kann und werde das Thema „Was ist agil?“ nur schwach ausleuchten können. Hier der Anfang des Versuches.

Werte und Methode

Meiner Meinung nach liegt der grundsätzliche Unterschied zwischen einer Methode und einer Wertesammlung darin, dass Du in einer konkreten Situation nicht sofort eine Handlungsanweisung findest (Methode), sondern kurz innehalten musst und schauen musst, wie du nach deinen Wertevorstellungen reagieren möchtest.

Machen wir uns nichts vor, diese bewusst reflektierende Art ist sehr schwierig und selbst die, die es schaffen, schaffen es nicht 24/7. Denn so sind wir Menschen: Unterbewusst. Unser Unterbewusstsein handelt ständig nach unseren eigenen Werten. Diese zu benennen ist ein hartes Stück Arbeit, aber sie bewusst zu ändern eine wirkliche Aufgabe.

Der Kreis schließt sich

Und hier kommen die Methoden ins Spiel, vielmehr die sog. agilen Methoden. Sie sollen Dich dabei unterstützen die agilen Werte zu leben, indem sie Haltepunkte, Leitplanken und Leuchtfeuer definieren, an denen Du Dich orientieren kannst. Sollbruchstellen für Dein Unterbewusstsein hinzuschauen, bewusster handeln zu können und nachhaltigen Wandel zu implementieren.

Als Freiberufler komme ich mit vielen Firmen in Kontakt, die entweder Scrum kennen, einführen wollen oder es schon getan haben. Auch Projektanfragen drehen sich oft um Scrum und Agil.

Der erste Punkt der mir dann oft auffällt, ist, dass die Menschen mit denen ich darüber rede beides in einen Topf werfen. Wenn ich Scrum mache bin ich auch agil. Leider stimmt das nicht. Ein Grundsatzartikel:


Hinter agil steckt nicht, wie viele aus dem Wort ableiten: Ich mach einfach wie ich lustig bin. Vielmehr haben irgendwann (2001) schlaue Menschen niedergeschrieben welche Werte bei erfolgreichen Projekten gelebt wurden und haben dies das „Agile Manifest“ genannt.

Es geht also um Werte, nicht um Prinzipien oder gar Methoden. Auf Seite zwei leiten sie aber Prinzipien ab, denen sie folgen.

Merke: Wenn Du über Agil sprichst, sprichst du über Werte, nach denen Du arbeiten willst.


Scrum ist eine Methode. Stell‘ dir sich eine Pyramide mit drei Scheiben vor, Werte sind die Grundlage, darauf bauen Prinzipien auf und die kleinste Scheibe oben, das sind die Methoden, wie z.B. Scrum. Methoden sollen Prinzipien und Werte unterstützen. Denn die Werte will ich leben und im Unternehmen verankern, da nur das aktive Leben der Werte ein Unternehmen langfristig stabil und performant macht.

Merke: Scrum für sich genommen ist nur eine seelenlose Methode. Mehr nicht.


Es kommt also oft vor, dass ich mit Menschen über die seelenlose Hülle Scrum spreche und diese Menschen davon ausgehen, dass das schon agil ist. Vielfach sprechen wir dann über reinsten Cargo-Kult.

[…]Das Kriegsmaterial, das während des Zweiten Weltkrieges massenhaft von der US-Armee auf diese Inseln abgeworfen wurde (Fertigkleidung, Konservennahrung, Zelte, Waffen und andere Ware), brachte drastische Änderungen des Lebensstils der Inselbewohner mit sich: Sowohl die Soldaten als auch die Einheimischen, die sie beherbergten, wurden mit Materialmengen regelrecht überschüttet. Oft wurden dafür eigene Wohnstätten und Nahrungsvorräte vernichtet und Landepisten und Flugplätze im Dschungel für die erwarteten Frachtflugzeuge gerodet. So wurde etwa Hollandia (heute Jayapura) zu einer großen Marinebasis ausgebaut, wo 1944 ca. 400.000 US-amerikanische Soldaten stationiert wurden. Die Nachwirkungen dieser Invasion auf die indigene Bevölkerung spiegelte sich in der Nachkriegszeit im Bau zahlreicher „Cargo-Häuser“ wider.

Mit dem Kriegsende wurden die Flughäfen verlassen und kein neues „Cargo“ wurde mehr abgeworfen. Darum bemüht, weiter Cargo per Fallschirm oder Landung zu Wasser zu erhalten, imitierten Kultanhänger die Praxis, die sie bei den Soldaten, Seeleuten und Fliegern gesehen hatten. Sie schnitzten Kopfhörer aus Holz und trugen sie, als würden sie im Flughafentower sitzen. Sie positionierten sich auf den Landebahnen und imitierten die wellenartigen Landungssignale. Sie entzündeten Signalfeuer und -fackeln an den Landebahnen und Leuchttürmen.[…]

Wikipedia, 19.12.13, 12:15 MEST


  • „Können Sie bei uns Scrum innerhalb von 3 Monaten einführen?“
  • „Bitte übernehmen Sie auch die Funktion des Product Owners“
  • „Im Daily Standup frage ich immer ab, was das Team so getan hat“

Die Schlange kann viele Köpfe haben. Die Ursache ist immer die selbe: Hier wird versucht ein Problem mechanisch zu lösen. Scrum (oder Kanban, oder…) als Allheilmittel, aber nur als Methode eingesetzt. Die Werte werden ausgeklammert, nicht verstanden und nicht gelebt. Dann kann es nicht zu einer nachhaltigen, intrinsischen Verbesserung führen!

Liebe Mitmenschen. Macht Scrum oder Kanban als Methode, aber bitte: Nennt es nicht agil!


Am 19.04.2013 fand im Startplatz Köln die 1. Kanbankonferenz 2013 der Limited WIP Society Cologne statt. Die Minikonferenz bestand aus zwei Votraägen, einer Einführung in das Thema Kanban von Matthias Bohlen und einer Case Study von Thomas Epping, und einer anschließenden Diskussionsrunde, die ich moderiert habe.

Alles fing damit an, dass wir in der #lwipcgn genannten Kanban-Usergroup überlegten, wie wir Kanban auch im mittleren Management bekannter machen können. Gleichzeitig kam die Anfrage der Limited WIP Society D-A-CH, ob wir nicht die Konferenz der DACH ausrichten könnten. Beides zusammen ergab die Idee der Konferenz als Einstieg und Werbemittel. Da uns aber das leane Gedankengut bekannt ist, begannen wir erst einmal mit Iteration 0 und im kleinen Umfang und Kreise.


Im Kreis endete die Mini-Konferenz auch, da ich das Goldfischglas (s. Fish-Bowl) als Werkzeug für die Diskussionsrunde gewählt hatte. O-Ton eines Teilnehmers:

„Insbesondere die Diskussion am Ende war sehr hilfreich, das Für und Wider besser zu verstehen oder auch die Fallstricke in der Realität zu sehen. Es kam mir nicht vor wie 90 Minuten – was ja immer ein gutes Zeichen ist.“


Viele Teilnehmer sprachen uns im Anschluss darauf an, dass sie Bedarf an einem 2. Teil der Konferenz hätten und gerne mehr in die Tiefe gehen wollen. Das ist der feste Plan für die Zukunft.