Newsletter | Echte Teamarbeit ermöglichen

"Mit [Teamarbeit] werden schneller Lösungen generiert und sie unterstützt bei komplexen Aufgaben, in denen unterschiedliche Expertisen notwendig sind." Prof. Guido Hertel erläutert im Interview "Teamarbeit: >Zurücknehmen, um das Ziel zu erreichen<", was echte Teamarbeit ausmacht.

Er ordnet Design Thinking als Methode ein, mit der interdisziplinäre Teams zum Erfolg kommen können: "Dabei werden unterschiedliche Leute in einem interdisziplinären Team zusammengebracht, um noch innovativere Ideen als in konventionellen Teams zu entwickeln."

"Moreover, because distracted managers tend to be shortsighted, they often find themselves overcommitted." Wer sich zu viel auf den Zettel packt, der verliert den Fokus. Diese Wahrheit gilt für Teammitglieder genauso wie für Führungskräfte. Heike Bruch und Sumantra Ghoshal bieten in "Beware the Busy Manager" ein Modell an, mit dem Ihr Defokussierung von Führungskräften in die Sprachfähigkeit (oder in die Erkenntnis ;-) heben könnt.

Dr. Arne Roock plädiert in "Thoughts on Survivor Bias" dafür, dabei nicht den Fokus auf Erfolgsgeschichten Anderer zu setzen: "We look at a set of visible data and conclude what must have happened in the past".

Er warnt vor der einfachen Kopie: "I just disagree with the (implicit or explicit) conclusion that we, too will become successful by doing the same thing."

In dem 49-minütigen Video "Rethinking Leadership" gibt Andrea Provaglio praktische Tipps, wie agile Führung gelebt werden kann: "Leadership is about creating the change you believe in". 

"Schreiben, Löschen, neu schreiben" ist Programmieralltag. Yevgeniv Brikman hat in "The 10:1 rule of writing and programming" Logs analysiert und die "10:1"-Regel gefunden: [...], the ratio of >code churn< to >lines of code< in mature and non-trivial software is also at least 10:1." Das macht deutlich, warum die Frage nach dem Aufwand schwerer zu beantworten ist als die Frage nach der Komplexität einer Aufgabe. 

Kent Beck erläutert in "test && commit || revert" eine sehr einfache Regel für eine bessere Codequalität mittels Test Driven Development: "If the tests fail, then the code goes back to the state where the tests last passed." Die Entwickler und Entwicklerinnen werden anfangen, kurze Codestücke zu commiten -- und Software wird besser, wenn sie mehrfach geschrieben ist.