inventedhere

Teamarbeit macht Spaß, kann aber auch beschwerlich und anstrengend sein. Wenn man intensiv zusammenarbeitet gehören Reibung und Spannungen einfach dazu. Oft unterscheiden sich Ansichten, Ziele und Vorgehensweisen der Teammitglieder. Oft führen fehlendes Verständnis und Engagement der anderen zu Demotivation und Enttäuschung. Wieso bringt Sie sich heute nicht ein? Wieso reagiert Er heute so gereizt? Manchmal könnte man meinen, es läge an der allgemeinen Stimmung im Team oder vielleicht sogar dem Projekt an sich. Fälschlicherweise, denn es könnten genausgut die persönlichen Umstände des einzelnen Teammitgliedes sein.

Um diesen Phänomen vorzubeugen, beginnen wir bei inventedhere jedes Meeting mit einem Ritual, dem sogenannten Check-In: Zu Beginn des Meetings beschreibt jedes Mitglied kurz seinen eigenen Gemütszustand. Bin ich entspannt? Habe ich genug geschlafen oder bin ich anderweitig im Stress? Vier Sätze genügen, um den anderen mitzuteilen, wie meine momentane Verfassung ist. Verhalte ich mich dann  unangebracht, kann der Rest des Teams das entsprechend einordnen ohne es auf sich selbst zu beziehen.  So steigert der Check-in die Empathie im Team und sorgt für mehr Harmonie und gegenseitiges Verständnis bei der Arbeit. Eine Check-Out Runde am Ende des Meetings hilft um über das eigene Verhalten im Team zu reflektieren.

In meinem derzeitigen 12-Wochen-Projekt in der d-school kamen wir im brainstorming sehr schnell auf eine wunderschön einfache Lösung für unser Problem, die mangelnde Motivation der Mitarbeiter unseres Projektpartners. Bereits der erste Prototyp, ein Satz Buzzer, mit dem die Kunden ihre Zufriedenheit anzeigen sollten, wurde von uns liebevoll aus Styropor, Stoff und Ipad gebastelt.
Unser erster Test mit einem unserer Teammitglieder brachte jedoch nicht den gewünschten Erfolg. Im Gegenteil, Martin war zunehmend verärgert, dass seine Anstrengungen sich nicht in höherer Zufriedenheit unserer Testkunden zeigte.
Obwohl wir ihn in unserer Präsentation eine Woche später bereits als verworfene Idee anführten, tauchte er bei der nächsten Ideen-Auswahlrunde wieder auf. Der Prototyp gefiel uns so sehr, dass wir uns einfach nicht von ihm trennen wollten. Ein kurzes Gespräch mit Madeleine, einer D-School Studentin mit Hauptfach Psychologie, brachte weitere grundlegende Fehler der Idee zum Vorschein.
Kurz gesagt, irgendwie mussten wir uns von der Idee verabschieden, um uns auf andere und Erfolg versprechendere Ideen zu konzentrieren, die uns zuerst weniger sexy erschienen. Um den Abschied diesmal endgültig vollziehen zu können, entschlossen wir uns, die Idee im Garten der D-School offiziell zu begraben.
Die Bilder zeigen deutlich die Trauer aller Teammitglieder.

Die Teammitglieder bei der "Beerdigung"

Das "Ideengrab"

Was kann man daraus lernen? Ich glaube es ist wichtig, Ideen, die man liebt, obwohl sie nicht funktionieren, in irgendeiner Form von Ritual zu begraben, um einen definitiven Schlussstrich zu ziehen und sich nicht weiter von anderen, besseren Lösungen abzulenken. Das muss nicht unbedingt ein Begräbnis im D-School Stil sein. Ein großer Ideen-Papierkorb, oder eine spezielle Ecke für verworfene Ideen kann ausreichen, wenn das Begraben mit Zustimmung aller in irgendeiner Form zelebriert wird, und ein “Abschied” von dieser eigentlich so geliebten Idee stattfindet.

Professor Kees Dorst explains his interpretation of Design Thinking in a short video, and how the methodology might be implemented in a business context. He says, that in a nutshell, Design Thinking is not so much about finding a solution but more about rephrasing a problem, about taking a new point of view to tackle a problem (what he calls a new “frame”).

In the article (Kees Dorst | Interpreting Design Thinking) that accompanies the video, Dorst analyzes critically the current hype on Design Thinking and then offers an interesting framework to understand how Design Thinking might be applied for innovative processes in business context.

A recommended read for everybody who is interested in Design Thinking and its application in the “real world”.

Recently I participated in the workshop “Future Fun Course”. Obviously the course conducted with on Design Thinking. So I thought I knew what was going to happen there: brainstorming, doing points of view and everything. Even though I consider myself a savvy Design Thinker (as if you could ever be that), I always welcome connected events as a great way to expand my design thinking toolbox, e. g. learning new warmups or other brainstorming methods.

This time I took away an amazing exercise based on building a team and learning to work within it. I was startled by the results and took away an import learning for myself so I figured, you might want to try it, too.

The Lego Exercise is a great thing to do in the early stages of teamwork. Be it in school, at companies or at the D-School before immersing yourself in a new project. It does not necessarily have to take place in the beginning of a process. The learnings that participants can take away from it are worthwhile in any stage of teamwork.

To do this exercise you need a set of cards with individual tasks on them. You can download and print the one we have prepared or just copy the questions. Hand out one card to each team member. We found that seven people each team is the ideal number for doing the exercise. You also need a bunch of good old Lego bricks. I use this set, which comes in a handy box. It has enough bricks even for two teams.

The goal in this exercise is to build a Lego construction as a team. At the same time, each member of the group has to make sure, that her or his task from the card is achieved within the construction. Now this would be easy if it wasn’t for the fact that no one is allowed to talk after having received the cards. Give it twenty minutes and watch the teams. Afterwards the teams should take some time to evaluate the process and what they have learned from it.

Most common insight is, that it sometimes makes sense to let your team members just go for their aims. As you watch the LEGO construction grow you understand, where the team wants and needs to go. Another learning is the importance to understand and respect each team member’s individual goals. You will see it is useful and necessary to integrate them into the overall goal of the team.

It is also very interesting for a coach to watch the individual needs embedded in the construction. When I introduced the exercise at the D-School, the two teams who took part came up with completely different kinds of constructions:

One of the teams during the exercise

2 completely different results

A few weeks ago we were planning our first Design Thinking Workshop with the company SponsorPay in Berlin. They had asked us if we could help them create a workshop that would leverage the knowledge of their employees to generate ideas for the future strategic orientation of the company.

We agreed and set a short term date with the company’s boss. We had done a lot of Design Thinking at the D-School and all felt comfortable with the process. However, we never taught somebody else the method.

We had our schedule and the content ready and had less than five days to the actual workshop. At that point we all became more and more nervous if we would deliver a fun and insightful experience, just as we knew Design Thinking. SponsorPay had committed to give 20 employees half a day off to take part in the workshop. Their comittment and trust in us was high, even though they knew, it would be the first time for us. Hence we felt we should deliver a top product.

Building the prototype
After much discussion and in face of the early date we decided to run a prototype of our workshop. Voices were loud it would be a waste of time and we should rather use the time to refine the materials and our schedule or even do more research on the company’s issues. In the end the pro-prototypers made their point. We invited our friends for a five hours prototype after work at my place and of course for some pasta and beer afterwards.
What fun that workshop was with a ditzy design challenge and a bunch of friends! Yet more importantly the learnings we got from our little workshop were decisive for the real one. I would say it was worth at least a week of working on workshop materials or schedule.

Using the learnings
The day after the prototype we met at the SponsorPay office and gathered the learnings and feedback from last night.

Two insights really made us happy and they changed the whole workshop. Since one of us had to observe the happenings and document the feedback, I was out of the  process of our two teams. That really had an impact, the master of ceremony was created. Somebody outside the teams helping out with the look the outside or motivating, whenever a team is stuck. She or he conducts the “orchestra” in the background, always an eye on the clock and on the rules. Hence we reduced the number of teams and I (again) was the master of workshop ceremony.

As we tried our Design Thinking lectures on fun task we did each lecture before the actual step and then wanted our friends to jump up and go for it with the just presented tools. But. We looked in a rather wondering, maybe confused audience. Our friends made their point pretty fast. They did not see the clear goals to reach after each stage of the Design Thinking process. Thus they did not know what to do next and moreover how to use the tools.

We substantiated the design challenges and remodeled the mini lectures that would introduce each process stage. We also made the process more tangible with our bag of tricks. A few improvements in the schedule were necessary.

The final workshop was a rocket. There where no major hickups, everyone had fun and after the lecture the guys from SponsorPay really went for it right away! I believe everyone took away some great learnings. For me personally, the most important learning was that if you are uncertain if something is going to work out the way you have planned it, there is no better way then testing a prototype. Get rid of the idea that prototyping is for physical products only and start prototyping experiences, processes, ads, behaviour … just everything. “Prototype everything” just as George Kembel of Stanford’s d.school would tell you.

As a matter of fact, we are currently prorotyping a name for our team … we give it 2 weeks. Afterwards we will see how everybody felt with it and what kind of feedback we got from people who heard the name. We just stopped discussing why one name is better than the other and just did one.