This post is inspired by the article "Ex-Valve employee describes ruthless internal politics at 'self-organizing' companies" in PC-Gamer, which in turn was triggered by a stream of tweets by Rich Geldreich.

I am writing this to share my experience from working at it-agile GmbH. It is not my intention to prove Rich wrong (I am not questioning his experience), but to provide an alternative view on what working at a company with a non-tranditional structure can be like - and what might be necessary to make it work.

Disclaimer: this is purely my personal perspective and opinion. Nobody at it-agile (or elsewhere) approved of this text. I am writing this during my vacation, out of passion for this way of working.

A bit of background: it-agile was founded in 2005 by three colleagues who where unhappy about how they were treated by their boss. Today (July 2018) we are 42 permanent employees, currently growing quickly. About 65 percent of the company is collectively owned by all permanent employees.

I joined it-agile in 2009 and went through a couple of phases since then: excitement, puzzlement, frustration (for halve a year, I seriously considered quitting). Today, I would describe my relationship to my company of choice as mainly dominated by appreciation - for the joys and difficulties of working in such a structure, for being able to be part of such a "social experiment", and for my colleagues, who, despite all our differences, are willing to invest into our shared journey.

In all those years, we learned a lot about how to run a "boss-less" company - and we are still learning. And that's definitely not always fun.

For the rest of this article, I will pick a couple of Rich's tweets that I feel I can provide an interesting alternative or complementary perspective on. I will skip those that are specific to working in a software development team.

I can see at least two reasons why that would often be the case.

First, if you take away formal hierarchy, it will quickly be replaced by an informal hierarchy. There will always be people who have more influence than others. The company culture will quickly reflect the values in action of those top influencers. And even if they espouse values of cooperation etc., they will have learned tools of coercion that they fall back to when things get rough. They just don't know any alternatives.

A central hurdle is that the tools of coercion actually had an important function: creating "alignment". If you take that tool away without replacing it by alternative structures that fulfill that function, it's very easy to loose cohesion over time - at some point, it might easily feel like anarchy has broken out.

The only working alternative that I am aware of is social pressure, created by "brutal transparency" and shared responsibility. At it-agile, every co-worker can see how I spend company money, and every cent I spent affects the profit share of everyone else. If I do something that seems irresponsible, I will get strong feedback, sometimes in a way that is hard to digest.

If that doesn't sound nice - well, it isn't. It can be very productive, and actually fulfilling, though. For that, we had to invest a lot into acquiring new skills, though - especially skills that help us to deal with conflicts in an effective way. If you don't posses those skills, it's easy to imagine how it would result in a culture of anxiety. (Interestingly, at it-agile it resulted in a culture of false compromises and frustration. So, it doesn't have to be anxiety.)

So, in summary, if you think you get a "self organizing" company by just taking away or reducing the formal hierarchy, I am not at all surprised if you end up with increased anxiety.

True. Navigating (and shaping) the social network becomes a much more important skill when you take away the hierarchy. Personally, I would rather learn this one, than learning how to game the formal hierarchy.

Also, you can put structures and agreements in place to deal with the negative effects of triangulation (aka office politics). At it-agile, we have developed a shared understanding that if we talk about a coworker, we hold each other responsible for then also talking with said coworker about the topic that bothers us.

Seems that part of the confusion here is that "self organizing" isn't really well defined. (As far as I know, Human Systems Dynamics even argues that every social system is self-organized - in a traditional company, people just self-organize around hierarchical constraints.)

As Niels Pfläging argues much better than I could, flatter hierarchies are not the answer, decentralization is. And it comes with the challenges mentioned above.

A lot of Rich's tweets reference the existence of such a "corporate arm". His advice seems to revolve around how to use that fact for your advantage, or at least survive it. If I'd ever decided to work for such a company, only if I'd see a chance that that "arm" actually would be interested in getting reflected their (negative) impact and change their behavior.

There are whole books written about why (individual) bonuses are a really bad idea in today's workplace. That is true doubly so for "self-organizing" companies.

Having said that, a fair compensation structure is a very complex problem to solve, that we haven't fully figured out yet ourselves. I am not even sure that it's possible. We are experimenting with variations of different approaches for years now, and are in constant dialog about it. That's the most important thing for me: I can talk about what bothers me, and I have an impact by doing so. I also understand that what would work best for me, wouldn't work well for everyone of my colleagues.

Putting teams inside the company in competition to each other - another stupid idea that becomes even worse in a self-organizing company.

What you do want, is teams holding each other accountable. A team at it-agile that seems to struggle will get asked "what are you doing to get out of the struggle", but also "what help do you need". A team that does exceptionally well will get asked how they do it - both to learn from it, but also to make sure they don't overwork themselves and steer into burn-out.

This is an interesting tweet. I would rather say "if you're running a self-organizing company, what the heck do you mean by self-organizing?" A self-organizing company, by my definition, isn't run by a single person (or small group of people).

Having said that, it's true that it pays to have someone who has an eye on the company atmosphere (which is much more than just anxiety level). In 2016, we introduced the role of a company coach for that (though not just that) purpose. It's a rotating role, that one colleague fills full-time, assisted half-time by another colleague. Remember: these are colleagues who would otherwise be out there making money for our shared profit. And we all decided together that it's worth it.

After skipping a couple of "corporate arm" tweets, this one stood out for me.

At it-agile, an interview is done by at least four self-selected colleagues. If I have a strong doubt about a hire, I can be part of the interview. And all those colleagues in the interview need to agree to make an offer.

Interestingly, shared profit has the exact opposite effect: the better the recruit, the more profit he will produce, the bigger my profit share.

I would emphasize that that can happen to you simply because you don't know how to run a self-organized company. At it-agile, at one point the level of frustration became so high, that we feared if we'd just continue, we all would quit in a matter of two years. And nobody wanted that level of frustration or was willingly benefitting from it.

We took that as a trigger to explicitly invest lots of time and money into learning how to better deal with conflicts. We got professional external help, and created internal roles responsible for supporting the process. And that process still isn't finished, though we have a much better understanding of the necessary skills and processes today, and the working atmosphere and culture has improved considerably. (Interestingly, the year we started investing into this, profit also increased noticably.)

OK, I could write much more, but I am getting tired, and this is already quite longish for a blog post. If you are interested in something specific, I will happily answer your comment. Or, if you read German, you can look at the book that I am very slowly writing on LeanPub: "Wir arbeiten hier trotzdem".
Ich habe in den letzten Wochen darüber nachgedacht, wie Agilität Effizienz fördert und sammle meine Gedanken in einem Artikel, den ich in einer der nächsten Ausgaben der agile review veröffentlichen möchte.
Ich veröffentliche den gegenwärtigen Stand hier vorab, weil ich hoffe, dass er bereits "gut genug" ist, um euch nützlich zu sein – und weil ich hoffe, durch euer Feedback die weitere Arbeit effizienter zu gestalten.

Agilität und Effizienz

von Urs Reupke

In den letzten Wochen bin ich umgezogen und renoviere jetzt die alte Wohnung. Viele Teilaufgaben führen mich durch Abende voll Beschaffung,Transport und Handwerk. Immer wieder frage ich mich abends: Hat sich das gelohnt? Habe ich effizient gearbeitet?
Daraus wuchs die Frage, was Agilität und Effizienz miteinander verbindet.

Was ist Effizienz?

In der Wikipedia heißt es, Effizienz sei der rationale Umgang mit knappen Ressourcen; der Ausdruck eines guten Verhältnisses von Kosten zu Nutzen. Effizienz bewertet also, ob wir die Dinge richtig tun.

Der Wunsch nach Effizienz ist der Hintergedanke der Spezialisierung in Taylors Theorie des Scientific Management und damit die Grundlage vieler Organisationsstrukturen und Vorgehensmodelle.

...nothing quite so useless...

Peter Drucker hat dazu schon 1963 beobachtet:
It is fundamentally the confusion between effectiveness and efficiency that stands between doing the right things and doing things right. There is surely nothing quite so useless as doing with great efficiency what should not be done at all.
Auf diesem Gedanken fußen auch agile Methoden, die ihren Fokus stets zuerst auf Effektivität richten. In meiner Arbeit als Unternehmensberater begegne ich immer wieder Managern und Teams, die diesen Fokus kritisieren und einen Mangel an Effizienz beklagen.

Disziplin und Exzellenz

Dabei handelt es sich um ein Missverständnis: Effektivität geht vor, aber sobald wir das Richtige tun, ist Effizienz von größter Bedeutung.

Deswegen fordern agile Methoden mehr, als nur die Arbeit zu priorisieren: Agile Methoden erfordern Disziplin und ein unablässiges Streben nach Exzellenz – in der Zusammenarbeit, in der Technik und in der Struktur Ihrer Organisation.

Diziplin bedeutet für den Einzelnen und für das Team, den Verlockungen einfacherer, angenehmerer Aufgaben zu widerstehen und das Ziel für das Produkt und das Unternehmen im Auge zu behalten.

Für die Zusammenarbeit und die Wahl der Aufgaben heißt das, dass Vorlieben zurückstehen hinter Wertschöpfung für den Kunden. In der Technik äußert sich Disziplin in der Qualität des Ergebnisses, auch wenn der Weg zu einer zufriedenstellenden Lösung nicht offensichtlich ist. In der Organisation zeigt sich Disziplin in der schonungslosen Ausrichtung an Kunden und Markt, die Nabelschau und Machtspiele verhindert.

Das Gut-Genug-Prinzip

Effizienz ist immer Effizienz der Handlung. Was wäre also effizienter, als nicht zu handeln und dadurch schon Nutzen zu schaffen?

Im Agilen Manifest heißt es deswegen:
Simplicity – the art of maximizing the amount of work not done – is essential.
Handlungsleitend kann dabei Paretos 80/20-Regel sein. Zur Erinnerung: 20% des Aufwands liefern 80% der Ergebnisse und 80% der Kunden sind mit 20% der Ergebnisse bereits zufrieden – solange das Richtige priorisiert wird.

Mit überraschend wenig Aufwand könnten wir also bereits ein gutes Ergebnis erreichen mit einem hervorragenden Verhältnis von Kosten und Nutzen – und genau das ist Effizienz.

Ich nenne dies das „Gut-Genug-Prinzip”: Gut genug ist gut genug.

Das bedeutet: Sobald „gut genug” erreicht wurde, sollten Kosten und Nutzen für jeden weiteren Schritt genau gegeneinander abgewogen werden. Möglicherweise können wir uns bereits jetzt etwas widmen, in dem wir mit weniger Aufwand wirksamer wären. Im Optimalfall etwas, womit wir unsere Kunden begeistern!


Agile Methoden betonen zu Recht Effektivität. Sie ist die Voraussetzung für Effizienz, für ein gutes Verhältnis von Kosten und Nutzen, das bereits in Agile Methoden eingebaut ist.

Es ist an uns allen, unsere Arbeit daran auszurichten – und vorher schon das Richtige zu tun. In meinem Fall also diesen Artikel im Zustand „gut genug” zu lassen (hoffentlich) und mich wieder dem Renovieren zu widmen.

Was passt? Was fehlt? Ich freue mich auf eure Kommentare.

Wir bei it-agile in München sind ein recht chaotischer Haufen. Wir lieben unsere Freiheit, sind alle sehr unterschiedlich und haben es uns zur Aufgabe gemacht, zu einem erfolgreichen Team heranzuwachsen.
Der klassische Weg klingt verlockend: Wir schauen auf die Auslastung der Kollegen und ziehen uns genau die Anfragen, die uns eine stetige Auslastung bringen. Damit sorgen wir dafür, dass wir die in unserer Branche übliche 80%-tige Auslastung erreichen. Das ist zumindest das Ziel, das ich von meinen vorherigen Firmen kenne.

Doch die Natur unseres Geschäfts macht uns dabei viel zu schaffen: Länger als zwei Monate im Voraus kann keiner von uns planen. Kunden haben Unterstützungsbedarf unabhängig von unserer Planung. Meist sehr kurzfristig. Hinzu kommt, dass wir unsere Kunden nicht dauerhaft von uns abhängig machen wollen, sondern sie möglichst schnell in einen Zustand bringen wollen, in dem sie uns nicht mehr brauchen. Das widerspricht natürlich dem oben genannten Ziel. Hinzu kommt, dass wir den Kollegen Wahlmöglichkeiten für die Auswahl von Jobs bieten wollen. Nicht jeder Job den wir machen könnten, sollten wir auch machen. Neben genügend Geld verdienen steht das Interesse der Kollegen, herausfordernde und spannende Jobs zu machen. Schließlich ist die Zufriedenheit der Mitarbeiter mindestens genauso wichtig wie die der Kunden.

Wir brauchen also einen anderen Ansatz.


Diesen Haufen Steine bekommt jeder Kollege und kann damit seine im Jahr verfügbare Arbeitszeit verplanen

Wenn wir uns unser Problem anschauen, ein Umsatzziel in einer nicht-planbaren Umgebung zu erreichen, stellt sich schnell raus, dass es ein Limitierungsproblem ist. Kurzes googeln zeigt, dass ein Jahr 250 Arbeitstage hat (zumindest in Bayern 🙂 ). Die Ausgangsfrage lässt sich also darauf reduzieren, dass jeder Kollege an jedem Tag entscheiden kann, welche Art von Arbeit er macht: Arbeitet er für einen Kunden, bildet er sich weiter, arbeitet er intern oder macht er Urlaub. Für jeden Tag im Jahr muss diese Entscheidung getroffen werden. Klingt wie gemacht für Kanban-Karten: jeder Tag ist ein Signal, dass dort eine bestimmte Arbeit verrichtet werden kann.

Nichts leichter als das: wir besorgen 250 verschiedenfarbige Lego-Steine für jeden Kollegen und teilen diese in fünf Kategorien: 140 für Kundenarbeit (orange), 20 für Weiterbildung (blau), 30 für Orga (gelb) und 30 für Urlaub (weiß). Dann bleiben noch 30 für Slack (grün), also ungeplante Zeit übrig. Damit ist die gesamte verfügbare Arbeitszeit eines Jahres abgebildet und wir schauen uns regelmäßig an, wie viele Steine jeder Kollege verbraucht hat. Wir betrachten unser System retrospektiv und können für jeden Augenblick sagen, wie wir gerade dastehen: wir kennen die durchschnittliche Erwartung an ausgegebenen Steinen und die tatsächlich erzielte Anzahl. Damit haben wir ein Bild, ob wir gerade über oder unter der statistischen Erwartung sind.

Natürlich reicht das noch nicht. Rein statistisch steht jedem Mitarbeiter pro Monat 2,5 Tage Urlaub zu. Die Realität zeigt jedoch, dass Kollegen den Urlaub nicht gleichverteilt nehmen, sondern sich diesen zum Beispiel für einen ausgedehnten Sommerurlaub aufsparen. Die Konsequenz davon sollte sein, dass wir in nicht-Urlaubszeiten mehr orange, also Kundentage, und weniger weiße Steine sehen, da hier der Kollege Urlaub anspart.


Unser Teamkalender aus LEGO – Es gibt vier Reihen von links nach Rechts in denen die Monate abgebildet sind. Links oben Januar, rechts unten Dezember


Jeder Kollege hat eine Reihe um seine Steine zu setzen – Hier zu sehen: Januar, Februar und April, Mai

Um das abzubilden, ist es naheliegend, das gesamte Jahr als Kalender nachzubauen und darauf alle Steine zu verteilen. Damit haben wir ein für das Jahr abgeschlossenes System und können die Auswirkungen der tatsächlich erzielten Arbeitsverteilung auf die Zukunft direkt erkennen. Das heißt ich deale mit mir selbst. Macht ein Kollege mehr Kundentage als im Durchschnitt, wird sofort sichtbar, dass er in der Zukunft mehr Urlaub, Slack oder Weiterbildung machen muss. Und umgekehrt.


Das Dealen läuft in 4 Schritte ab: 1) Ich stelle fest, dass sich etwas ändert und ich tauschen möchte. In dem Beispiel möchte ich an den zwei Tagen Slack gerne beim Kunden sein. 2) Ich machen den Platz an dem die Steine standen frei. Ich entferne den Slack. 3) Ich suche mir eine nicht geplante Stelle, von der ich Kundensteine entnehmen kann und entferne diese. 4) Ich setze die entnommenen Steine an die zu ändernde Stelle und umgekehrt. Der Slack wandert jetzt also an die vormalige Kundenstelle und ich kann beim Kunden sein

Was ist aber, wenn jemand mehr Urlaub haben möchte oder mal eine größere Weiterbildung machen will? Hier beginnt das Teamdealen. Wenn ich mehr weiße Steine haben will, muss ich die von einem Teammitglied „abkaufen“ indem ich orange Steine eintausche.

Wir sind noch mitten in der Erfahrungssammlung mit unserem neuen System. Bisher können wir sagen: die Lego-Steine geben uns die individuelle Freiheit bei gleichzeitiger Betrachtung des Team-Ergebnisses. Mit unseren jeweiligen 250 Steinen kann jeder planen, so wie es ihm damit am besten geht. Und wir sehen auf unserem gemeinsamen Kalender sofort, welche Auswirkungen unsere Entscheidungen auf das Teamergebnis hat und ob wir etwas anpassen wollen.

Habt ihr Anregungen wie wir das System noch verbessern können? Dann schreibt uns. Wir freuen uns, die Ideen auszuprobieren.

A few months ago, I had the opportunity to join Craig Larman at a client for an informed-consent workshop on Large-scale Scrum (LeSS). Ever since I took his class in 2015, I was interested in how he starts off a LeSS adoption – or potential LeSS adoption, I should say. He asked me to do a write-up.

We had overall four days at the client. The first day was half Legacy TDD and half Impact Mapping. For day two and three we were off-site from the client with about 30 employees from different departments including finance and controlling, organizational development, and the CEO. The final fourth day we spent back at the client answering questions, and a three hours all-hands introduction to LeSS.


Craig shared a google document with me, that he also shared with the client. There were a couple of things he made sure up-front, including a description of the company, questions from client to Craig, from Craig to client, and the invitation mail to the workshop participants among the motivation part for LeSS. That was interesting to me since I usually do that verbally or on the phone, whereas a shared document appeared straightforward to me.

Half-day Legacy TDD

On the first day, we spent the morning on some legacy code. We had about 10 developers joining us. Craig gave a short introduction to TDD and the difference to Legacy TDD. Then we worked in a mob with a rotation of a few minutes. In those four hours, we managed to write two tests for one of their legacy PHP classes. The first test appeared a bit daunting, but Craig also explained lots of things around dependencies, how to deal with them, differences between stubbing and mocking, etc., etc. It paid off for the second test, as we were able to write that faster since we already had some scaffolding from the first test in place.

Half-day Impact Mapping

In the afternoon, we spent another four hours with the product management group. Most of them were called Product Owner, but also the CEO and one of their Scrum Masters joined us. Craig explained the general approach and had the group identify a goal. Then the group worked through the impacted persons towards the impact that they needed to achieve there in order to get closer to the goal. We also mapped some of the deliverables that were already in their backlogs. At the end of the day, the group took a longer time to agree on a goal, so that we didn’t have time to actually estimate the impacts, and the deliverables, so that Craig explained the steps that were missing.

What strikes me about the first day was that Craig spent a day at gemba in a value-adding way. He worked with the programmers on their production code in the morning, and with the product group in the afternoon. In both cases, he was able to add value to different groups while getting an overview of how work is done at the client.

Workshop Day 1

In general I had a pretty good impression of the workshop. Craig led through the Thinking Tools behind LeSS. He started off with Occupational Psychology, and how fear hinders any adoption. We worked in great length through the different kinds of waste, queueing theory, and created Causal Loop Diagrams for a couple of dynamics that were the main motivation behind the elements in LeSS. Craig avoided to mention anything LeSS specific on day one. Instead he made the point for one backlog per product quite clear, in that the dynamic with more backlogs, i.e. one backlog per team, leads to sub-optimal identification with the customer. Compared to the course I took in February 2015, I found that the argumentation followed a clear line. Thus I could see the improvements to the material in action since then.

Workshop Day 2

On the second day, we dived deeper into LeSS with a short introduction on the framework as well as some adoption notes. We spent the second half of the second day with Craig’s deep dive into questions that had come up. Anyone who has attended Craig’s course probably knows what I’m talking about. Craig spent lots of time to get deep into the answer so that participants grasped the context of the answers and thoughts behind LeSS.

Day 3 Q&A and Informed Consent

On day 3 we spent the morning with other potential coaches and some volunteers back in the client’s office. We worked through some open questions, and then Craig urged the group to come up with next tiny steps to do before starting bigger changes in a month or two. He also ran an anonymous non-committing poll on whether the group wanted to go with LeSS. There were two objectors, eight in favor (iirc), and the majority of the group would go along, i.e. not resisting, but also not actively pushing forwards. Personally I think they identified way more next steps as I would have called suitable for the one or two months timeframe.

After that I had to leave for my train ride home, but Craig also did a whole company introduction to LeSS. I don’t know what happened there, though.

The overall goal of the four days was to make an informed decision at the client to either go for LeSS or something else. Craig made sure that the client made the decision where to go, and made sure that people in the workshop could understand potential side-effects. Together with the Causal Loop Diagrams they should be able now to evaluate their future struggles.

PrintDiggStumbleUpondel.icio.usFacebookTwitterLinkedInGoogle Bookmarks

Eben gerade habe ich dem Webinar von Jeff Sutherland und Ken Schwaber gelauscht, in dem die aktuellen Änderungen am Scrum-Guide erläutert wurden. Viel hat sich nicht geändert, aber ein Abschnitt zu den Scrum-Werten wurde hinzugefügt, im englischen Original findet er sich hier.

Wie zu erwarten sind es die folgenden fünf Werte geworden, die bereits von Ken Schwaber in seinem ersten Scrum-Buch veröffentlicht wurden. Interessanter Weise haben Ken und Jeff eine Reihenfolge gewählt, um die Werte zu erläutern, auch wenn sich diese Reihenfolge nicht im Scrum-Guide wiederfindet.

  • Commitment: Das Commitment des Teams und des Managements sind nötig, damit Dinge wirklich angegangen werden und wirklich erledigt werden mit voller Energie. Das Team versucht nicht nur das Sprintziel zu erreichen, es ist darauf committet!
  • Fokus: Erfolgreich kann man nur sein, wenn man sich auf seine Aufgabe fokussiert (und auch ein Commitment ohne Fokus ist vermutlich nichts wert).
  • Offenheit: Gerade für Wissensarbeit gilt, dass Offenheit mehr Optionen schafft und eine größere Chance darauf bietet, dass man gemeinsam eine bessere Lösung findet. Es sollten auch alle wissen, was gerade das größte Problem ist, damit jeder zur Lösung beitragen kann. 
  • Respekt: In gewisser Weise ist Respekt eine Voraussetzung für Offenheit. Denn nur, wer sich respektiert fühlt, wird auch offen zu seinen Schwächen stehen können.  
  • Mut: Offenheit, Veränderung und das Ansprechen von Problemen benötigt Mut. Zudem benötigt auch der Einsatz von Scrum Mut, weil man die vielen Vorteile von Scrum nicht ohne den Nachteil großer kultureller Veränderungen in der Organisation bekommt. 

It’s been a while since I wrote code these days. Back in late April however I found myself in a Coding Dojo at the Düsseldorf Softwerkskammer meet-up working on the Mars Rover Kata. I have a story to share from that meeting. However, since I tried to reproduce the code we ended up with that night, and I decided to give JUnit5 (and Java8) a go for that, I ended up with a struggle.

Back in the days with JUnit4 I used the ParameterizedRunner quite often to use data-driven tests. I never remembered the signature of the @Parameters function, though. The Mars Rover Kata also includes some behavior that I wanted to run through a data-driven test, but how do you do that in JUnit5? I couldn’t find good answers for that on the Internet, so I decided to put my solution up here – probably for lots of critique.

Please note that I used JUnit 5.0.0-SNAPSHOT which is a later version than the alpha, but probably not the final one.

JUnit5 offers besides Java 8 capabilities some interesting new things. JUnit5 comes now with Extension capabilities where you may influence the test’s lifecycle and also ways to resolve parameters to your tests, and your test class constructors. And then there are TestFactories for DynamicTests. Woha, quite a lot new stuff.

First I tried stuff with parameter resolvers. But then I would have needed to keep track of the parameters, and I had to call the parameter resolver more than once. So, combining it with an extension might work? No, I couldn’t make that work. So, dynamic tests are the way to go.

So, here is an example for what I ended up with. We have a Direction class with a method called turnLeft(). The idea is if the Rover is headed NORTH, and turns left (by 90 degrees) then it will be facing WEST.

Some notes:

  • I kept a collection of test data in a field in line 17. This is somewhat similar to the old way you annotated a function with @Parameters in JUnit4, even though you can now get rid of the Object[], and use a private test data class per test class. That at least seems to be the solution that I preferred.
  • For the @TestFactory you have several possibilities. I decided to use the Stream return type here in line 28. As I haven’t programmed too much in Java 8, I am not sure whether my usage is appropriate here. The conversion of the testData from the Collection is quite straight-forward, I found.
  • For each operation I wrapped the assertion in line 36 to avoid making the call to dynamicTest more convoluted than necessary. I also decided to generate a descriptive string for each test with the method in line 32. I think you can come up with better ways to generate the test descriptions. Wrapping the assertion on seemed unavoidable though. I especially didn’t like the usage of the lambda-expression together with the aggregate expression seems to make the line with dynamicTest (line 29) less readable than I would like to. I think there is more improvement possible.
  • Note that you can have several @TestFactory methods on your test class. So when writing a test for turning right, you can provide another TestFactory and reuse the test data for that. I’ll leave that as an exercise for the inspired reader of my blog.

So, this is what I ended up with. I think there is still room for improvement, especially when you compare the result with stuff you might write in tools like Spock.

P.S.: I ran this through Marc Philipp – one of the JUnit5 originators – in an earlier version, and he told me that they will be working on a more elegant solution for data-driven tests, probably for one of the next releases of JUnit5.

PrintDiggStumbleUpondel.icio.usFacebookTwitterLinkedInGoogle Bookmarks

Usually I don’t write many promotions for other’s contents on this blog as I try to keep it personal and focused on my personal views. Recently I was contacted on the International 2016 State of Testing report, and whether I would like to do a write-up about it. I asked whether it would be ok to post a personal view, so here it is.

Demographics – and what do they tell me?

The top areas from the report are Europe (& Russia), USA, and India. I think these are also the biggest areas when it comes to software testing. The demographics tell me that the data according to my impressions is not very biased but well-spread.

About a third of the respondents work across four different locations. Another third work in a single location. My personal view on this is that there is a good mix of testers working in one location, and way more spread across different locations. I think this might stem from different out-sourcing companies as well as companies working across different sites for various reasons – even though this usually makes the formation of real teams hard – at least in my experience.

Most of the respondents have working experience of five years or more. I think the majority of testers new in the field usually don’t get immediately their attention on such kind of surveys. I think this is tragic, as in the long run we should be working on integrating people new to the field more easily.

There also appear many test managers in the survey data. This seems quite unusual to me, as there certainly are way more testers than test managers – I hope. This usually raises the question to me how come there are so few testers passionate about their craft. In some way this is tragic, but it resembles the state of the industry.

Interestingly on time management, most time of the testers seems to be spent on documentation (51%) and dealing with environments (49%). That’s sort of weird, but also resembles my experiences with more and more open source tools, and more and more programmers not really caring how their stuff can be tested or even brought to production. On the other hand I notice many problems with test data-centric automation approaches, where handling test data appears to be the biggest worry in many organization. I usually attribute that to bad automation, as an automated tests usually should be easy to deal with, and create its own test data set that it operates on – a problem well-addressed in the xUnit Test Patterns book in my opinion – but few people appear to know about that book.

Skills – and what you should look out for?

Which sort of transitions my picture to the skills section. Testers appear to use a couple of approaches, foremost Exploratory Testing with 87%. There are also 60% mentioning they use scripted testing. This also matches my experience since testing rarely is purely Exploratory or purely scripted. I think the majority of testers claiming they use Exploratory Testing is either a signal of the rise of context-driven testing in general, or a bias in the data. I think it’s more of the former.

I liked that test documentation gets leaner. With the former 51% of the spare time of testers spent with documentation, this is certainly a good thing. At the conferences I attend I see more and more sessions on how to use mindmaps for that. Quite a third of the respondents said they already used mindmaps. I think that’s a good signal.

Even though the authors claim that formal training is on the raise when it comes to skills of testers, and their respective education, there are still many testers trained through training on the job and mentoring, as well as learning from books and online resources. I think this is a good trend, since I doubt that formal training will be able to keep up with transferring skills in the long run. They can inspire testers to dive deeper into certain topics, but on-the-job training and mentoring, as well as active reflection from material that you read, is a good thing, and way more powerful.

Unsurprisingly communication skills are the number one necessary skills for testers (78%). The next skillset that a tester needs according to the survey is on functional testing and automation, web technologies, and general testing methodologies. That resembles sort of my past as a tester, and which skills I put efforts into. Unsurprisingly 86% of the respondents claimed that they have test automation in place.

More Agile – less concerned

It seems that waterfall approaches are on the decline, even in the testing world. In 2015 42% mentioned they used Waterfall. In 2016 it were only 39%. 82% responded they used Agile – maybe every once in a while.

Even though the testing community usually is concerned from the historic background on their job safety, this uprise of Agile methodologies didn’t lead to more testers being concerned. Compared to 2015 where 42% were not concerned about their job, in 2016 there are 53% of the folks unconcerned. Probably that might be related to more context-driven approaches being more wide-spread.

This is just a summary with certain picks from myself. I encourage to dive into the State of Testing survey report on your own to get more details.

PrintDiggStumbleUpondel.icio.usFacebookTwitterLinkedInGoogle Bookmarks

“Think. Create. Learn”: das war das Motto das Otto InnoDays 2016. Wie stellt sich die ganze Veranstaltung rückblickend vor dem Hintergrund dieses Mottos dar?

Motto: Think. Create. Learn.

“Think. Create. Learn.”: das war das Motto der InnoDays. Think und Create habe ich überall gesehen und gespürt. Das Lernen waren meiner Meinung nach etwas unterbelichtet. Sicherlich wurde viel auf technischer Ebene gelernt, auch bzgl. Machbarkeit (z.B. 3D-Druck von Gutscheinen). Und die Teams haben auch quantitativ etwas über den Markt gelernt. So hatten viele Teams Zahlen, Daten, Fakten über den Markt und bestimmte Nutzergruppen in ihrer Abschlusspräsentation. Mir fehlte noch das qualitative Lernen über den Markt – welche Probleme und Bedürfnisse haben real existierende Menschen (und nicht irgendein Durchschnitt) wirklich?


Für mein Gesamt-Fazit zu den Otto InnoDays wiederhole ich das, was ich bereits ganz am Anfang geschrieben habe:

Im Vergleich mit ähnlichen Veranstaltungen in anderen Firmen waren die Otto InnoDays 2016 auf jeden Fall ganz vorne mit dabei. Und wenn ich dann bedenke, dass Otto ein Konzern mit über 4.000 Mitarbeitern und kein eBusiness-Unternehmen mit nur 200 Mitarbeitern ist, ziehe ich meinen Hut. Von den Otto InnoDays 2016 können sich viele vermeintlich agilere Unternehmen eine große Scheibe abschneiden.

Ich habe an einigen Stellen deutlich etwas zu mäkeln gehabt (Einbindung von Endkunden, Vernetzung von Ideen), aber das ist im Vergleich zu anderen Unternehmen Jammern auf hohem Niveau. Ich hoffe, dass meine Mäkeleien dazu führen, dass die Otto InnoDays 2017 noch cooler werden als die Otto InnoDays 2016. Und dann lasse ich mich gerne wieder dazu einladen.

Mehr zu den Otto InnoDays 2016

Die weiteren Blogposts in dieser Blogpost-Serie finden sich hier.

After a long time of agility and philosophy, here's something technical for a change.


Yesterday, I was talking OO and functional programming with Alex Chythlook, who told me that some problems I faced in Anathema could have been solved much easier applying functional programming idioms.
When I asked for details, he pointed me to a talk Jessica Kerr (@jessitron) held at GOTO 2014.
Go here in case you're watching the talk and would like to actually see the slides.


All of her points are well made, and she's an entertaining presenter. I am happy that she pointed out some things that I didn't have names for previously.
However, I am surprised that many of these ideas are functional, as they just appear to be thorough applications of OO principles to me. If they have been functional all the time, then it is certainly good to call them thus.

What stood out

"Errors are data too" Jessica said and told us to "not interrupt the execution flow". 
I've long spoken out against checked exceptions, and this nails it: If I treat an error as data, I am forced to deal with it. Right now, just where I would process the good result. No handing the exception outward, no wrap-to-catch-later.
That way, Exceptions are limited to things that I, as a programmer, have not foreseen, and that's the way they are meant to be used.

Idempotence, something she touches on in the very end, is quite important, too. Good to have a word, now. It describes the idea that an executable block of code (so, a function or a Single Abstract Method object) should change the world only once, even if it's called multiple times.
From her talk, I picked up the notion that this should be true for every function, and I don't fully agree with that because complexity increases when I build things out of things that build things, even if those are just functions.

The third main takeaway was her call for Lazy Evaluation. Doing that forces you to think in Objects or First Order Functions, and prevents procedural style – and that should always be a good thing.

What appears to be OO

I first stumbled when Jessica introduced a service object to limit a function's access to the database. Isn't that an application of the interface segregation principle (ISP) and the Single Responsibility Principle (SRP)? 
Smalltalk people always told me that even in Java, the client should define the exposed interface, and this is just that: If I need a service that just inserts, the method should have access to only that.

Next, she speaks about specific typing - again, isn't that just OO? If something represents a name, I should call it "Name", not "String". The DDD people have said it since 2004 and hardly anyone listened, so Jeff Bay had to point it out again in his paper on Object Calisthenics some seven years ago, calling on us to "wrap all primitives and Strings" (and numeric objects, of course).
Applying this principle in classes and productive code, I can well say that it is a game changer - your code becomes much more clear and expressive this way, even more so when you apply his next rule – "use first order collections" - as well.
Back to Jessica: Good on her picking up on that, I fully agree. It surprised me, though, that she watered down the principle by us to Options and Tuples later on in her talk. Those two are never domain specific, so effectively, she just put two new primitive types on our plate. 
More recent languages have more elegant ways of expressing these concepts, and they might feel more at home there.
I was surprised once more when she presented the lack of concern about when or how my code is executed as a principle of functional programming. With the OO concept of encapsulation comes the idea of Single Abstract Method objects, which are handed around as executable blocks. She even pointed us to the GoF patterns Command and Strategy, so clearly, this has been around for a while and was considered OO back then. 
Did the GoF silently sneak in functional ideas? How dare they!

What I didn't quite get

Apart from these three good points, there was one I didn't get: Structural Sharing? What was it about, memory efficiency? Didn't she just tell us that we should rely on our compilers instead of doing their work?


So, all in all, it doesn't matter. Whether it's OO or functional, this is a good talk to watch. 
If you want to brush up on intermediate concepts of coding or see some examples of how things might get easier if you break your common patterns: Go watch!

Als Otto in Person von Sabrina Hauptman mich fragte, ob ich an den InnoDays 2016 teilnehmen wollte, war ich mir unsicher, wieviel mir das wirklich bringt. Schließlich hatte ich schon ähnliche Veranstaltungen besucht: Hackathon, FedEx Day und wie sie alle heißen. Und so richtig überzeugt war ich nie.

Erstmal sieht das alles ganz einfach und plausibel aus. Das Unternehmen möchte innovativer werden (wer möchte das nicht?) und bei vielen Entwicklern gibt es den starken Wunsch, die ganzen neuen Technologien mal auszuprobieren, die “da draußen” gerade angesagt sind.

Also lässt man der Kreativität der Entwickler mal einen oder zwei Tage lang freien Lauf und guckt mal, was herauskommt. Die Veranstaltungen sind dann auch durchweg cool. Man kann die Energie spüren und die Entwickler haben sehr viel Spaß. Das alleine ist für viele Unternehmen bereits eine große Anstrengung und respektiere den Versuch sehr.

Probleme mit vielen Hackthons

Meist ist es aber eben auch nicht mehr als ein erster Versuch:

  • Es gibt keinen definierten Prozess, was mit den Ergebnissen passiert. Es gibt lediglich die diffuse Hoffnung, dass irgendjemand “da oben” schon die Genialität der Ergebnisse erkennen und dann die Projekte in die Roadmap aufnehmen wird. Passiert aber nicht.
  • Die Ergebnisse sind meist extrem technisch (wer wollte nicht schon immer mal einen Hadoop-Cluster aufsetzen oder Docker in Docker laufen lassen?) und der Mehrwert für das Unternehmen bleibt unklar. Auch daher verwundert es mich nicht wirklich, dass niemand die Ergebnisse zu echten Projekten macht.
  • Radikale erste Ideen sind so gut wie immer Mist. So werden dadurch zu guten oder sogar großartigen Ideen, dass sie über einen längeren Zeitraum durch verschiedene Köpfe gehen und mit anderen Ideen kombiniert werden (siehe [Sawyer2008]). Das leisten die Hackathons, die ich gesehen habe, kaum oder gar nicht.

So sind viele Hackathons nicht viel mehr als ein Strohfeuer, als kurz aufflammt, aber letztlich keine Wirkung hat. Es kann sogar zu Frustration führen, wenn die Teilnehmer diese Wirkungslosigkeit erkennen.

Siehe zu dem Thema auch meinen Blogpost zum Konzept der Slack-Time, in dessen Kommentaren Markus Andrezak das Konzept als “Opium für die Massen” bezeichnet hat. Das trifft auch auf so manchen Hackathon zu: Tut er mehr, als die Entwickler zu beruhigen?

Otto InnoDays

Sicherlich ist es bereits eine bemerkenswerte Leistung, wenn ein Konzern wie Otto einen Hackathon wie oben beschrieben umsetzt und damit zeigt, dass sowas nicht den neuen hippen Internet-Unternehmen vorbehalten ist.

Trotzdem blieb für mich die Frage, was ich dabei lernen könnte.

Die ersten Otto InnoDays fanden 2015 statt – damals nur mit den internen Mitarbeitern der Entwicklung. 2016 wurden die InnoDays geöffnet für externe Mitarbeiter und für die Fachabteilungen. Das hört sich schon mal ganz gut an, weil es die Chance bot, aus dem reinen Techno-Fokus herauszukommen. Außerdem waren die Otto InnoDays 2016 sehr groß angelegt – mit einem Prozess, der letztlich zwei Wochen lang lief. Und die Organisation machte auch nicht irgendjemand “mal nebenbei”. Stattdessen stellte Otto nennenswert Kapazitäten für die Vorbereitung und durch Begleitung bereit. Die schienen es wirklich ernst zu meinen.

Damit waren meine Zweifel noch nicht ausgeräumt. Aber die Neugier begann zu überwiegen und so sagte ich zu.

Ziele und Ablauf der InnoDays 2016

Details… (folgen noch)

Otto InnoDays 2016: die ganze Geschichte

Dieser Blogpost ist ein Artikel in einer Blogpost-Serie.

Überblick über die ganze Blogpost-Serie…


  • [Sawyer2008] Keith Sawyer: “Group Genius: The Creative Power of Collaboration”
Letzte Aktualisierung des Planeten:
09:05 UTC